sending Challenge + EAP-Notification before Reject?

[David Mitton]

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 at freeradius.org>:

>
> On 19 Feb 2014, at 07:04, Stefan Winter <stefan.winter at 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 at freeradius.org>
> FreeRADIUS Development Team
>
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
>
>