forcing EAP-type based on client/request

[Alan DeKok]

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.