IPSK with RADIUS: how to avoid manual MAC provisioning

[Cusna]

IPSK is an amazing solution for many scenario and verticals.

The IPSK solution of Meraki without RADIUS supports only up to 50 PSKs per SSID, which is not really scalable.

The solution with RADIUS, however, requires the RADIUS to know in advance the MAC address of clients allowed in the network.

There are several solution out there that require users to manually enter their client MAC address (especially for headless devices, while other devices can be onboarded via a captive portal). This seems to me very complicated and prone to error and leading to a lot of support requests - it may work in campuses with young students but not much in senior living scenario).

Is there a solution to make this work without having the RADIUS to know in advance the client MAC address?

The Ruckus DPSK solution, attaches to RADIUS access-request some additional attributes that basically allow the RADIUS server to compute the PSK and, if correct, automatically add the MAC address to the client list (details here).

Any idea about how this could be implemented, right now, on Meraki?

[PhilipDAth]

If I understand correctly, you want to grant access to a device connecting based on a formula of some kind?

I would use FreeRadius for this.  You can follow the FreeRADIUS setup instructions here:

https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_RADIUS_Authentication 

I have not personally done this specific config, but FreeRADIUS lets you define a script to run for authentication.  You would need to write a script to do whatever calculation you want, and then return the allow/deny.

It looks like the simplest option in FreeRADIUS to do this is using the "exec" module:

https://networkradius.com/doc/3.0.10/raddb/mods-available/exec.html 

A Google seems to indicate there are multiple ways of solving this with FreeRADIUS.

[Cusna]

Thanks Philip for the feedback. 

Regardless the "formula" used, the point is that right now Meraki is not sending any information in the access-request that would allow the RADIUS server to understand who is attempting to connect, except for the MAC address of the client.

The other solutions referred above send some parameter that (with a "formula") allow the RADIUS server to see what passphrase the user entered. At this point I would have the user device MAC address and a passphrase to match him with a user account. Form here there are many cool experience that could be triggered to automatically provision that device without having the user to manually enter a MAC address anywhere.

[PhilipDAth]

>The other solutions referred above send some parameter that (with a "formula") allow the RADIUS server to see what passphrase the user entered.

Meraki is sending the PSK that the user entered to the RADIUS server.  It is in the "Tunnel-Password" RADIUS attribute.

https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_RADIUS_Authentication 

"The RADIUS server used for authentication can vary depending on the network. The Tunnel-Password attribute is the field that is used on the RADIUS server to bind the MAC address and PSK."

[Cusna]

My understanding (and tests) suggest that Meraki does not send it in the access-request (and for obvious security reasons). 

Is the RADIUS server adding it as attribute in the access-accept back to the AP, so the AP would start the 4-way handshake, and if the PSK entered by the user match the one the RADIUS replied with in the tunnel-password attribute, then the association will be successful.

So basically the RADIUS has no clue on what passphrase the user entered. If it finds the mac address of the client, then it replies saying "by the way... if the user entered this passphrase, let him connect"...

[PhilipDAth]

The Meraki AP *must* send both the MAC address and passphrase in the access-request, otherwise there is no way for the RADIUS server to validate the request to approve or deny it.

The AP does not decide if the user can access the network or not.  That is the job of the RADIUS server.

It is only a 2-way "handshake".  The AP sends an ACCESS_REQUEST message with all the details.  The RADIUS server responds with either an ACCESS_ACCEPT or ACCESS_REJECT.  That's it.  End of conversation.

[Cusna]

My understanding is that the AP only sends a MAC authentication request (with MAC as username/password). 

The RADIUS validates that the MAC address matches with a valid device (that's why the need to be added in advance).

If the RADIUS finds a match, replies with an Access Accept including the Passphrase (associated to the user and know to the RADIUS) in the Tunnel-Password attribute.

The AP, then, performs the WPA2 4-way handshake (ref) verifying the passphrase entered by the user in the client vs the one obtained form the RADIUS in the Tunnel-Password attribute.

[PhilipDAth]

I was wrong, you are correct.  That is how it works.

You are also correct - that is extremely limiting for what you want to do.

[Cusna]

As a matter of fact, we can achieve extreme flexibility in the use of PPSK with most of vendors because their PPSK-without-RADIUS mode supports many PSKs (not 50 like Meraki).
Ref: https://docs.cusna.io/

With Meraki, unfortunately we can't make this happen...
The only PPSK+RADIUS implementation I found that support this auto-provisioning is - unfortunately - Ruckus (look at this)