My RSA EAP-POTP method implementation can send EAP Notification messages in error situations... and I found that most EAP supplicants ignore them or worse. The RTM Windows 7 EAP client would drop them on the ground and not reply, a violation of protocol. They patched that to match prior behavior, ignore and acknowledge. I made it an option, and I think, turned it off by default in later releases. I've never seen anyone that passed the message up to the user, but they could be out there. Dave. Quoting Arran Cudbard-Bell <a.cudbardb@freeradius.org>:
On 19 Feb 2014, at 07:04, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
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.
This is not what I mean... converting Reply-Message is forbidden for a good reason (as you quote below): the authenticator can't be a pass-through any more if he actively "fiddles" with the EAP conversation on its own.
That's why the RFC language is so strong about the MUST about EAP-Notification and MUST NOT of Reply-Message in presence of the EAP-Message attribute.
Yes, i'm aware :)
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.
Well, that's better than nothing certainly. Guess what: I'm asking this question because we are currently setting up what we call an "EAP Lab" (working title) where a (Free- and others) RADIUS server can be tuned to behave "non-normal" so that we can test supplicant behaviour in such unusual situations. We were primarily aiming at "what if the server cert's issuing CA suddently changes" and the like, but EAP-Notification is great test vector to include.
That will be extremely useful, even just having an awareness of the steps to fix such issues supplicant side will make 802.1X enabled networks far easier to support.
We'll put your recipe above to the test on that lab and will ask back if in doubt (certainly :-) ) ... The EAP lab website is WIP, but you can always already go here: http://supplicants.net and click around.
Looks like a worthwhile project.
Seems like the inverse of what you have planned for supplicants would also be very useful, like standard test suites for the major EAP-Methods to ensure RADIUS servers and vendor equipment behaves correctly.
-Arran
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2