Can RADIUS indicate a standardised reason for access rejection?

[Michal Moravec]

Thank you for very insightful responses. 

One other thing I have noticed is that after the (Cisco Meraki) Access Point receives Access-Reject message from RADIUS it will disassociate the supplicant sending reason code 8 "Disassociated because sending STA is leaving or has left Basic Service Set (BSS)."
https://www.cisco.com/assets/sol/sb/WAP371_Emulators/WAP371_Emulator_v1-0-1-5/help/Apx_ReasonCodes2.html <https://www.cisco.com/assets/sol/sb/WAP371_Emulators/WAP371_Emulator_v1-0-1-5/help/Apx_ReasonCodes2.html>
There is a defined reason code (23) which seems to be more appropriate for the situation: "IEEE 802.1X authentication failed."

Do you know whether this reason code should be used?
If so what is the common practice? Do vendors do it?

However even with answer to that I don't know if this would help in my case since I can not inspect Apple Wi-Fi (Airport) code because it is closed-source (unlike kernel and 802.1X client).

MM

> On 18. 8. 2022, at 14:52, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Aug 18, 2022, at 4:14 AM, Michal Moravec <michal.moravec at macadmin.cz> wrote:
>> Imagine you use EAP-TTLS + PAP for 802.1X authentication. 
>> You have client which is able to authenticate.
>> One day password changes or expires (server-side). 
>> Client attempts to authenticate using the old password.
>> RADIUS server will reply with Access-Reject.
>> 
>> Can RADIUS server add some standardised message/attribute to the message indicating the reason for the rejection?
> 
>  In theory, yes.  In practice, no.
> 
>  RADIUS provides for Reply-Message, which is sent to the NAS, and then should be sent over a PPP link to the end user.  This doesn't work with EAP and Access Points.
> 
>  EAP provides for EAP Notification packets, which are sent from the Access Point to the supplicant (end user system).  Unfortunately, most supplicants treat this packet as a failure.  Worse, they never show anything to the end user.
> 
>> E.g. "reason: password expired", e.g. "reason: wrong password", etc.
>> The key is the "standardised". I know I can provide any reply message but here I would need to reply with something the client and/or NAS expect and can react to accordingly.
> 
>  The client has to show the message to the user.  And the clients don't do this.
> 
>> Reason for asking: Most of our clients are macOS devices. When user changes the password server-side, next EAP-TTLS + PAP authentication attempts fails. 
>> macOS displays very cryptic message about a connection problem (no prompt to enter the password).
>> Ideal behaviour would be client knowing the reason for authentication failure so it can react accordingly (prompt user for new set of credentials).
> 
>  TLS has various alerts (certificate expired, etc).  So far as I can tell, the clients don't show those to the user either.
> 
>  It's like they all have a policy against showing any useful information to the user.
> 
>  Alan DeKok.
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html