On 18 Feb 2014, at 17:19, Alan DeKok <aland@deployingradius.com> wrote:
Stefan Winter wrote:
recently, RFC4284 was brought to my attention, which speaks of ways to notify EAP peers that there is no service for them - with a displayable message as EAP-Notification in a Access-Challenge before the final EAP-Failure in a Reject.
IIRC, some switches will close the port when they receive an EAP-Notification in an Access-Challenge.
Is this in any way doable with FreeRADIUS?
Yes. Arran was doing this a while ago, which is how he ran into the above problem.
It is doable with FreeRADIUS, but FreeRADIUS wasn't doing when I was playing around with it. The NAS was translating Reply-Message into an EAP-Notification and sending it *after* the EAP-Success or EAP-Failure. This was causing wpa_supplicant to reinitialize it's state machine, and restart authentication, which is how I became aware of it.
I'm thinking of two scenarios primarily:
* FreeRADIUS proxy can't reach home server, so writes "Sorry, your home server is unreachable" in a Challenge+EAP-Notification and after the next Request then crafts Reject.
* FreeRADIUS sees the realm, figures that it's not wanted, so writes "We don't serve that realm here." and then after the subsequent Request sends Access-Reject.
I thought that the Reply-Message in an Access-Reject could also be turned into an EAP-Notification by the NAS. I can't recall where I saw that, though. But it would make sense.
RFC 3579 2.6.5. Displayable Messages The Reply-Message attribute, defined in [RFC2865], Section 5.18, indicates text which may be displayed to the peer. This is similar in concept to EAP Notification, defined in [RFC2284]. 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). Reply-Message attribute(s) MUST NOT be included in any RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet. Unfortunately RFC 3579 was released after HP had completed their 802.1X implementation.
I could also imagine that it could signal its own module failures as reason; e.g. if an rlm_sql doesn't work, instead of an immediate reject or do_not_reply it could send an extra round with "Unable to authenticate you: rlm_sql failed. Try again later"; and only then the Reject.
I have no clue how to configure such a behaviour. Is it possible at all?
Probably with some magic. But will the supplicants display the notification to the end user? I doubt it.
Indeed. - Yes you can send an EAP-Notification, but you should probably test whether any supplicants will actually display it before investigating this much further. Back when I looked at it in 2008, only the OSX supplicant did anything useful with it, and even then it was just writing it out to one of the system log files. You can fake a Challenge with unlang pretty easily for testing and just send it instead of the original EAP-Failure message. Use regex over %{hex:EAP-Message} to extract required ID field value. and to set the response type: update response { Response-Packet-Type := Access-Challenge } You may have to set the Response-Packet-Type immediately after calling EAP, I don't know if setting it in Post-Auth REJECT will work, and you'll also need FreeRADIUS 3.0.1 or higher. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2