forcing EAP-type based on client/request

[Kacper Wirski]

Hello,

Thank You for answer. That was exactly, what I was looking for.

"

   EAP includes the concept of negotiation.  The server proposes an EAP type.  The client can NAK it, and propose a different set of EAP types.  The server then chooses one, and uses it.

"

That's what I understood from all I read, that's why I was so surprised 
with the way I saw those devices operating.

Regards,

Kacper


W dniu 20.11.2018 o 03:36, Alan DeKok pisze:
> On Nov 19, 2018, at 2:04 PM, Kacper Wirski <kacper.wirski at gmail.com> wrote:
>> For quite some time I've been using freeradius (3.0.17 right now - installed from network radius packages on centos 7.5). I've been using it for 802.1x eap-peap mostly.
>>
>> I decided to expand my uses for RADIUS. The issue I ran into is that some of the devices/applications, that could benefit from more centralised RADIUS AA:
>>
>> - don't tell which "eap-type" they want to use
>>
>> - use only what's set as "default" in /mods-available/eap
>>
>> - require different eap types (one works only when using default = md5, other only when deafult = mschapv2) - so it's mutually exclusive.
>>
>> Those devices/applications have no way of setting eap-type, so right now with my knowle
>    That's not how EAP works.
>
>    EAP includes the concept of negotiation.  The server proposes an EAP type.  The client can NAK it, and propose a different set of EAP types.  The server then chooses one, and uses it.
>
>> Before writing this message I did look in the documentation, but I'm probably not experienced enough, to make much sense of it.
>>
>> What I understand is that, what should happen is this:
>>
>> - client  either explicitly tells which eap-types it wants to use (like with windows, I can explicitly choose eap-peap with mschapv2 for example), or sends just eap-identity, and freeradius starts offering types that are configured, then client/radius come into "agreement" which type to use.
>    That is what happens.
>
>> With those devices in radius debug it looks basically like this: there's eap-identity frame, radius tries using what's set as default, and it either works (if it's what client expected) or fails (if it expected other eap-type).
>>
>> I have in "eap" module enabled both mschpav2 and md5 and peap, but there can be only one "default" type.
>>
>> So what I was thinking, that maybe there's a way to set "eap-type" based on request? In documentation about default eap setting I read that "it's used, when eap-type wasn't set already by another module or just eap-identity was sent". That got me thinking that there might be some way "in another module" to force EAP-type based on coming request?
>    You can set EAP-Type manually:
>
> authorize {
> 	...
> 	if (foo) {
> 		update control {
> 			EAP-Type := PEAP
> 		}
> 	}
>
> 	eap
> 	...
> }
>
>    And it will set the EAP type only when the condition "foo" matches.
>
>    Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html