[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: forcing EAP-type based on client/request
From:       Kacper Wirski <kacper.wirski () gmail ! com>
Date:       2018-11-20 7:12:06
Message-ID: 9924fbc6-5688-96c5-a4f1-e9c9c4e3097d () gmail ! com
[Download RAW message or body]

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@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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]