Cisco Identity PSK – What is it, and how is it configured?

With WLC Code v8.5, Cisco has introduced a new feature called Identity PSK, also referred to as iPSK.  This post is intended to explain the purpose and benefits of iPSK, as well as show you how to configure the WLC, and ISE for iPSK functionality.

What is Identity PSK?

Traditionally, on a WLAN that is configured with PSK security, all devices share the same PSK.  Identity PSK is a feature that allows multiple PSKs (a unique PSK per client, if you so desire) to be configured on the same SSID, while optionally providing different levels of access to each client.  While this technology is not new to the industry (some other WiFi vendors have had different flavors of this available for quite a while), this is the first time we have been able to accomplish this on Cisco hardware.  Because it integrates with a RADIUS server, you can centralize the list of your clients/PSKs, instead of having to maintain lists of them on each WLC.

Why not just use 802.1x?

Because you may not be able to.  In many environments, you will encounter clients that do not support 802.1x.  Some common examples include older barcode scanners, medical devices, and building control devices.  iPSK allows many of the luxuries of 802.1x, while using clients that only support PSK.

What is the purpose of Identity PSK?

To best explain this, please consider the following example:

Let’s say you manage the wireless network at a large hospital.  Only recently have medical devices such as IV Pumps and Mobile X-Ray Carts begun to support 802.1x wireless networks.  Even if you are fortunate to have some of the newer devices that support 802.1x, chances are pretty good that some of the devices you are forced to provide connectivity for are likely upwards of a decade old.  If you’re lucky, those devices are capable of connecting to a WPA2-PSK network, and not limited to WEP!  Many times, the manufacturers of each of these devices will want their devices to be the only type of device on that subnet.  As a result, you have been forced to create multiple PSK SSIDs, so that each type of device (IV Pumps, X-Ray Carts, etc.) can have its own VLAN.  We all know the negative performance impact that each additional SSID can have on an environment.  Wouldn’t it be nice to be able to consolidate all of these different devices down to a single PSK SSID, and still be able to provide differentiated access to them?  Enter Identity PSK.

Another example:

You manage the wireless network of a school district, and your district purchased low-end netbooks that only support PSK.  You are aware of the security problem that exists if someone gets a hold of the PSK, and shares it with someone…  and you know they will.  Identity PSK would allow you to have a unique PSK for every one of the netbooks, and the PSK would be bound to the MAC address of the netbook itself.  If an attempt was made to use that PSK on another device, authentication would fail.

How does it work?

When a client authenticates to the wireless network, the WLC checks with the RADIUS server to see if the MAC address exists in the authentication policy.  If it does, the RADIUS server will respond with an ACCESS-ACCEPT, including the PSK as a Cisco-AVPair (in either ASCII or HEX, depending on how it is configured).  The ACCESS-ACCEPT doesn’t necessarily mean that the client will be allowed on the network.  At this point, the WLC has not yet verified the client’s PSK to the PSK stored in the RADIUS policy.  The WLC will now compare the PSK in the RADIUS response, to the one the client used to authenticate to the network.  If the PSKs match, the client will be allowed on the network (and any additional attributes sent by the RADIUS server, such as VLAN, QoS or ACL will be implemented).  It is important to note that the WLC does not send the PSK used by the client to the RADIUS server.

What are the requirements?

Your WLC will need to be running at least 8.5 code, and you will need to have a RADIUS server configured.  Virtually any RADIUS server will work, but some are more easily configured for iPSK than others.  It is not possible to implement iPSK without a RADIUS server at this time.

Here are the RADIUS Servers that I have personally tested with iPSK:

• Microsoft NPS: Works with iPSK, but is cumbersome to use, because all client MACs must be created as users in Active Directory (with the MAC address as the user and password).  If not configured properly, this could be a significant security risk (many “generic” users/passwords in AD is not a good thing).  These users should be put into a group with no file/print permissions.
• Cisco ISE: Easier to use with iPSK, because the client MACs can be assigned to Endpoint Identity Groups, and don’t have to be created as users.  Unfortunately, ISE costs money, and many customers already have Windows Servers in their environment that can run NPS.

Do all of my clients need to be in my RADIUS policy?

No!  I think the most practical approach to iPSK is to use a “common” PSK for most of your clients, and use unique PSKs for clients that you want to assign different VLANs, ACLs, or QoS policies to.  In order to have a “common” SSID (not bound to specific MAC addresses), your RADIUS policy must have a rule that returns an ACCESS-ACCEPT, with this PSK as a Cisco-AVPair.  Typically, this rule will exist directly underneath the rules for specific clients/PSKs.

Configuration of the WLC for Identity PSK

Assuming you are familiar with 802.1x SSIDs (with RADIUS), the configuration of the WLC is quite simple.  An Identity PSK SSID is kind of a hybrid between a PSK SSID and an 802.1x SSID.  Configure your SSID as you would any other PSK SSID, with the exception of a few additional details:

• Enable MAC Filtering in the L2 Security section
  
• The PSK that you configure on the WLC may actually not be used at all, if you are using unique PSKs for your clients.  You can still use a common PSK for most clients, but it will need to be configured in the RADIUS policy.  For simplicity, I usually input the “common” PSK in the WLC as well, because you must configure something in the PSK field.
• Configure the SSID to point to the AAA server(s) that you have configured for iPSK, just as you would for a typical 802.1x SSID.  This can be the same RADIUS server that you are using for 802.1x, but your authentication policies will have to be written so that they don’t conflict with one another.
  • Ensure that CoA is enabled, if you are using Cisco ISE as your RADIUS server.
  • Also ensure that you have your RADIUS server configured as a AAA Accounting server in the WLC, as well as a AAA Authentication server.
• Enable AAA Override in the Advanced section (required for assigning additional attributes to the connection, such as VLAN, QoS or ACL)
  
• If using Cisco ISE, choose NAC State: ISE in the Advanced section.  This setting is not required for other RADIUS servers.

That’s it!  In order for any client to connect to this SSID, your RADIUS server must be configured for iPSK.  Now you must configure the RADIUS server to authenticate your clients.

Configuring Cisco ISE as the authenticator for an identity PSK SSID

For the purposes of this guide, we will assume that ISE is already functioning in your environment (the WLC is configured and tested as an authenticating network device, etc.).  The menu structure and screenshots in this guide will reference Cisco ISE v2.2, but any version of ISE can be used with Identity PSK.

First, let’s talk about some general concepts here:

• In order to allow your devices to use different PSKs on the same SSID, you have to plan your approach on how granular you want the access control to be.  Keep in mind that every MAC address that you want to use with a unique PSK must be specifically referenced in ISE.  I’ll reference some common scenarios below:
  1. You want to segment groups of devices, and have each group use its own PSK
     • Create Endpoint Identity Groups in ISE that contain groups of MAC addresses for the clients in each group
     • Reference these groups in your authorization policy, and return the PSK for that group as a Cisco-AVPair in the Authorization Results (we’ll get into the details on the AVPair, below).
  2. You want most of your devices to use the same PSK, but allow a few devices to receive differentiated access, with a different PSK
     • Reference the specific devices in your authorization policy (returning AVPairs with the PSK and differentiated access attributes).  This can be done individually, or in groups.
     • Create a “catch all” rule in the authorization policy, which allows all other devices to use a “common” PSK by simply permitting access, without any differentiated access
  3. You are completely insane, and want each device on your network to have a unique PSK
     • In order to accomplish this, you will need to create an authorization rule for each device, and return the unique PSK for that device as an AVPair.

I’m going to focus on Scenario 2 above, since this seems to be the most common scenario that I encounter.  Also, it covers all of the necessary configuration steps required to meet any of the scenarios above.

Configuration Steps:

1. Create an Authorization Profile Result, which will return the differentiated access attributes that you wish to use.  In this example, we will simply be assigning a VLAN to the connection
   • Policy > Policy Elements > Results > Authorization Profiles
     • Name: VLAN 172
     • Common Tasks
       • VLAN=172
     • Advanced Attributes
       • Cisco-av-pair = psk-mode=ascii
       • Cisco-av-pair = psk=wifireference
     • Screenshot of the above configurations:
       
     • Ensure that the details table at the bottom of the Authorization Profile includes the information discussed above
       

        

       • The “Tunnel-Private-Group-ID” is the VLAN attribute, and you can see both av-pairs listed as well
   • Submit your changes!
   • Repeat this process as many times as you need, depending on the different levels of access you want to provide to different groups of clients.
2. Now we need to create an Endpoint Identity Group that contains the MAC addresses of the clients that will be authenticating to the network.
   • In this example, I’m only going to include the MAC of a test client, but in the real world, these groups will usually contain large lists of MAC addresses.  The important thing to note is that this group of MAC addresses will be referenced in the RADIUS rules, and treated as one group of clients.  These groups of clients must all have the same PSK, and must all receive the same level of access.  You’ll want to segment your clients into different groups, if you want to differentiate access between them.  You only need as many Endpoint Identity Groups as is necessary to meet your differentiated access requirements.
   • Administration > Identity Management > Groups
     • Add a New group
       • Ensure that Endpoint Identity Groups is selected on the left-hand side of the screen
     • Name: Special_PSK_Devices (Note: You cannot use spaces here)
     • Submit
     • Click on the group you just created, to open its details
     • Add the relevant MAC addresses to the group
       
       
     • Save your changes!
   • Now this group of MAC addresses can be referenced in the Authorization Policy
3. Create an Authorization Policy (or modify an existing policy) for the Special PSK clients (which you defined in the Endpoint Identity Group)
   • Policy > Authorization Policy
   • This ruleset acts much like a firewall rule base, in that it is referenced top-down, and the first match wins.  As a result (pun intended), you must be very careful about the order of your rules.  More specific rules are usually above the more general rules.
     • You may also have device management rules in this list (for logging into the WLC, etc.).  Be careful to make each rule specific enough so that it won’t accidentally be referenced by another connection type.
     • For purposes of simplicity, we will create a rule at the top of the list, so that we know it will get hit with our connection.
   • On the right side of the top-most rule, click the small down arrow, and choose Insert New Rule Above
     

      

     • Define the rule
       • Name: iPSK Special Devices
       • Conditions:
         • IF
           • Endpoint Identity Groups > Special_PSK_Devices (the Endpoint Identity Group you created earlier)
         • and
           • Select Existing Condition from Library > Compound > Wireless MAB
       • Permissions
         • then
           • VLAN 172 (the profile you created earlier)
     • Click Done
     • Your rule should look similar to this:
       

        

       • Note: The Pencil in the left column indicates that this rule has not yet been saved/applied.  You must save your changes on this page before the rule can be tested!
         
     • Optionally, you can be more specific, and include the SSID name in the rule (so that other connections don’t inadvertently hit this rule)
       • Click the “+” in the attribute column that contains Wireless MAB, and add a new condition
       • Click the Gear icon on the right hand side, and choose Add Attribute/Value
         
       • Ensure that the operand between the rules is “AND”
       • Click Select Attribute, choose “Radius” and “Called Station ID [30]”
         
         
       • Change “Equals” to “Ends with”, because the Called Station ID Field includes information other than just the SSID
         

          

         • Pro Tip: If you are going to use this information in your rule, you will want to verify that your WLC is configured to send the SSID as part of the Called Station ID RADIUS Attribute.
         • In the WLC, Select Security > RADIUS > Authentication, and verify that the “Auth Called Station ID Type” has the SSID at the end of the string.  Most commonly, this will be set to AP MAC Address:SSID, which means the attribute will include the MAC of the AP the client is connected to, and the SSID the client is connected to, separated by a colon.
           
         • Your rule should now look similar to this:
           
         • Be sure to save your changes, when you are finished with the rule
     • You can duplicate this rule, and change the specifics, if you have many groups that you want to authenticate
4. Now we need to create a rule for the clients using the “common/general” PSK.  Remember that even clients using the PSK that is configured in the WLC must receive an “ACCESS-ACCEPT” from RADIUS, in order to be allowed on the network.  That means there must be a rule in RADIUS that allows this connection.
   • This is basically a simpler version of the rule you just created.  You don’t need to reference an Endpoint Identity Group, and you don’t need to have a specific AuthZ Result
   • Add a new rule below the rule you just created
     • Name: iPSK General
     • Conditions
       • If
         • Any
       • and
         • Wireless MAB (reference previous rule on how to select these attributes)
           • AND
         • Called Station ID Ends With “IdentityPSK” (Your iPSK SSID Name)
     • Permissions
       • then
         • Permit Access
   • Your rules should now look similar to the following:
     
5. You can now test your iPSK configuration!
   • Test a client that exists in the Endpoint Identity Group, with the unique PSK
     • Test that same client with the general PSK (It should fail)
   • Test a client that is not in the Endpoint Identity Group with the general PSK
     • Test that same client with the unique PSK (it should fail)
   • Here is what a successful authentication with the unique PSK looks like in ISE:
     • Note the proper Authorization Result, Identity Group, and perhaps most important, the Matched Rule
       
       
       
       
       

At this point, you have successfully implemented iPSK!  You can now build on this foundation, and create rules for multiple groups of devices, with different PSKs.