Using RADIUS CoA for reauthenticate STA

Daniil Sliusar sliusardaniil at gmail.com
Thu Sep 1 00:22:06 PDT 2022


Hello Alan, 

Thanks for reply. 

>  CoA is about changing authorization.  i.e. "change from 10Mbps to 100Mbps".  It's not about reauthenticating subscribers.
> 
>  If you want to reauthenticate subscribers, you have to use disconnect messages.  There are no provisions for reauthenticating users while keeping their connection "up". 
> 
>  The underlying protocols simply don't work that way, and don't support it.  It's impossible.

Actually it’s not 100% true. Many NAS vendors support CoA in a way to reauthenticate session without disconnect. 
For example Cisco/Meraki supports CoA with special VSA 'subscriber:command=reauthenticate’ to force dot1x auth 
process for existing client session. 

As from Meraki documentation: 
> When the server sends a CoA request, the client is not completely disassociated from its RADIUS session. Instead, the AP sends a new EAP request to the client to reauthenticate
 
Anyway if there are any other options (not with RADIUS - like wpa_cli or ubus) to reauth the client session - it would be great to hear them.
Thanks in advance! 


Kind regards,
Daniil Sliusar



> On 1 Sep 2022, at 00:19, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Aug 31, 2022, at 11:55 AM, Daniil Sliusar <sliusardaniil at gmail.com> wrote:
>> There is anyone who used CoA to reauthenticate subscribers without their disassoc / deauth
>> from Wi-Fi network? Could you please provide an example?  
> 
>  I'll speak from the RADIUS perspective.
> 
>  CoA is about changing authorization.  i.e. "change from 10Mbps to 100Mbps".  It's not about reauthenticating subscribers.
> 
>  If you want to reauthenticate subscribers, you have to use disconnect messages.  There are no provisions for reauthenticating users while keeping their connection "up". 
> 
>  The underlying protocols simply don't work that way, and don't support it.  It's impossible.
> 
>> I'm confused about the RADIUS CoA interface, that was implemented in commit "HS 2.0: CoA-Request
>> processing for Terms and Conditions filtering" (f456940ef359b420b54df2f2578b49c6ff2baa04).
>> There are no examples or any info on Google about it. We use build with CONFIG_HS20 enabled.  
>> 
>> Current examples: 
>>>> echo "Calling-Station-ID=7e:1a:bb:1d:4f:33" | radclient -x IP:3799 disconnect XXXXX
>> Works well. 
>> 
>> But:
>>>> echo "Calling-Station-ID=7e:1a:bb:1d:4f:33" | radclient -x IP:3799 coa XXXXX
>> Stuck on 
>>>> hostapd: DAS: No supported authorization change attribute in CoA-Request from
> 
>  I'd look at the hostap code to see what authorization changes it supports.
> 
>  But it doesn't make much sense to say "Change authorization for user X", and then have no *new* authorization attributes in the packet.  hostap is correct to complain here.
> 
>  Alan DeKok.
> 




More information about the Hostap mailing list