sending Challenge + EAP-Notification before Reject?

[Arran Cudbard-Bell]

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

-------------- 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: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140219/bb34f441/attachment-0001.pgp>