How I can properly send error reasons for EAP requests Access-Reject?
I have a requirement to provide the reason why authentication failed. For non-EAP clients, it is easy just include Reply-Message in Access-Reject packet. But for EAP clients RFC says Reply-Message should not be sent with EAP-Message together. First I've tried to include the second EAP-Message attribute with a reason using `EAP-Message+= "error code"`. I.e. supplicant will receive first EAP-Message with reply from some "eap" module and then my custom message. At least eapol_test tool sees both attributes, but I didn't test it with end-user devices. And I've read RFC 3579 more. In §2.6.5 Displayable Messages the RFC saying "An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet." First question why it saying this? I am confused because in real life I see EAP-Message attribute in Access-Reject response EAPOL: SUPP_BE entering state RECEIVE Received 44 bytes from RADIUS server Received RADIUS message RADIUS message: code=3 (Access-Reject) identifier=8 length=44 Attribute 79 (EAP-Message) length=6 Value: 046a0004 Attribute 80 (Message-Authenticator) length=18 Value: 9f3224d1705f2e3cb32708dbea4cc348 STA 02:00:00:00:00:01: Received RADIUS packet matched with a pending request, round trip time 1.05 sec But ok, assuming this is fine, there is § 2.6.3. Conflicting Messages saying " Access-Reject packets SHOULD have only one EAP-Message attribute in them, containing EAP Failure." I bet this forbids me from using this hack EAP-Message+= "error code" I didn't find the exact wording that says if you want to include "error code" in Access-Reject reply use only EAP Notification. §2.6.5 saying "When sending a displayable message to a NAS during an EAP conversation, the RADIUS server MUST encapsulate displayable messages within EAP-Message/EAP-Request/Notification attribute(s)" But I guess this is the proper way to do it. The second question - am I, right about it? Or there is another proper way to send an error reason? If I am right about the EAP-Notification attribute can I ask to provide an example of how to do it properly? Since RFC says to use Access-Challenge for notification and then disconnect probably I can try to adapt the example site "challenge". But maybe it is overkill. All I need as I imagine is to send "Access-Challenge " from Post-Auth-Type REJECT section the first time and when the supplicant will repeat the request, send Access-Reject for the second time. -- Vladimir
On 03/08/2022 16:24, work vlpl wrote:
I have a requirement to provide the reason why authentication failed. For non-EAP clients, it is easy just include Reply-Message in Access-Reject packet. But for EAP clients RFC says Reply-Message should not be sent with EAP-Message together.
Because the NAS gets the Reply-Message attribute, not the end user device, which only sees the EAP transaction. So Reply-Message will never get to the user.
And I've read RFC 3579 more.
No EAP supplicants display a message back to the user. So there's no point worrying what any of the RFCs say. If the supplicants being used don't do it, then you can't do it. -- Matthew
On Wed, 3 Aug 2022 at 17:31, Matthew Newton <mcn@freeradius.org> wrote:
So Reply-Message will never get to the user.
My requirement to provide an error reason does not care about users. I need to access the error reason on the Access Point side.
So there's no point worrying what any of the RFCs say. If the supplicants being used don't do it, then you can't do it.
Does this mean I can try to use 2 EAP-Message attributes or even Reply-Message, and if this will work I can stick with that?
On Aug 3, 2022, at 11:39 AM, work vlpl <thework.vlpl@gmail.com> wrote:
My requirement to provide an error reason does not care about users. I need to access the error reason on the Access Point side.
Then update the NAS software to look at the Reply-Message.
So there's no point worrying what any of the RFCs say. If the supplicants being used don't do it, then you can't do it.
Does this mean I can try to use 2 EAP-Message attributes or even Reply-Message, and if this will work I can stick with that?
Use Reply-Message. You can't send 2 EAP-Message attributes. Alan DeKok.
On Wed, 3 Aug 2022 at 18:12, Alan DeKok <aland@deployingradius.com> wrote:
Use Reply-Message.
Thank you!
You can't send 2 EAP-Message attributes.
Yes, most likely this is not counted as 2 EAP-Messages, because I read in RFC that they should be concatenated. But this is what I see in the eapol_test output. Received 51 bytes from RADIUS server Received RADIUS message RADIUS message: code=3 (Access-Reject) identifier=8 length=51 Attribute 79 (EAP-Message) length=6 Value: 045b0004 Attribute 80 (Message-Authenticator) length=18 Value: 3c2cba56f12f77053c8264207be0a8d2 Attribute 79 (EAP-Message) length=7 Value: 6572726f72 STA 02:00:00:00:00:01: Received RADIUS packet matched with a pending request, round trip time 1.05 sec And with unlang I am doing next update reply { EAP-Message += "error" }
On Aug 3, 2022, at 12:25 PM, work vlpl <thework.vlpl@gmail.com> wrote:
Yes, most likely this is not counted as 2 EAP-Messages, because I read in RFC that they should be concatenated. But this is what I see in the eapol_test output. Received 51 bytes from RADIUS server Received RADIUS message RADIUS message: code=3 (Access-Reject) identifier=8 length=51 Attribute 79 (EAP-Message) length=6 Value: 045b0004 Attribute 80 (Message-Authenticator) length=18 Value: 3c2cba56f12f77053c8264207be0a8d2 Attribute 79 (EAP-Message) length=7 Value: 6572726f72 STA 02:00:00:00:00:01: Received RADIUS packet matched with a pending request, round trip time 1.05 sec
OK...
And with unlang I am doing next
update reply { EAP-Message += "error" }
Don't do that. Use Reply-Message. EAP-Message is calculated automatically by the EAP module. It's supposed to contain EAP packets, not random text. Alan DeKok.
participants (3)
-
Alan DeKok -
Matthew Newton -
work vlpl