forcing EAP-type based on client/request

[Kacper Wirski]

Hello,

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

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.

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?

So please, If there is something obvious that I'm missing, please point
that out, I'm open to anything (except for maybe setting another FR
server just to use different EAP-default setting and split client
devices between those, that seems like an overkill to me?)

Regards,

Kacper


-
List info/subscribe/unsu

[Alan DeKok]

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.
- 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.
- 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.freeradi

[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

Post by Alan DeKok

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.
- 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.
- 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?

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

-
List info/subscribe/unsubscribe?