sending Challenge + EAP-Notification before Reject?

Arran Cudbard-Bell a.cudbardb at
Tue Feb 18 18:49:49 CET 2014

On 18 Feb 2014, at 17:19, Alan DeKok <aland at> 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

Unfortunately RFC 3579 was released after HP had completed their 802.1X

>> 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.



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 at>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <>

More information about the Freeradius-Users mailing list