eap-ttls/mschapv2 versus eap-peap/mschapv2 behaviour
olivier at heliosnet.org
Thu Jul 18 18:14:47 CEST 2013
On 18.07.2013, at 17:42, Alan DeKok <aland at deployingradius.com> wrote:
> Olivier Beytrison wrote:
>>> And EAP-MSCHAPv2 runs inside of PEAP. So the code should always go
>>> EAP -> PEAP -> EAP-MSCHAPv2
>> Ran the server in gdb, and couldn't verify this. That's what I had :
> The stack trace should be much larger than that. PEAP creates a
> "fake" request, and calls rad_authenticate() again, for the inner-tunnel
Weird. That's what I get for each call to mschapv2 functions.
>> The main point I'm discussing here is that, at least on OUR side
>> eap-ttls/mschapv2 and eap-peap/peap-mschapv2 are the main method used by
>> our clients.
> Try eapol_test, and eap-ttls/EAP-MSCHAPv2. You'll see the same thing
> as with PEAP.
Yeah it will be the same.
>> But I think, for consistency, that attributes added in authz should be
>> made available in post-auth. The base code is here (accept_vps being
>> saved), it just needs to be used at the right time.
> I think this is the same as v2, right? Or am I missing something...
> If it's the same as v2, we'll fix it in the next release.
Well I can't tell. In my last servers running v2 I didn't implement the short-circuit logic, so the ldap module is called on every packets (those were my first freeradius server and the config is horrible)
Well I implemented the cache module as I had before, but maybe this could be an enhancement for a future release (either in then server core or through a policy using rlm_cache)
More information about the Freeradius-Devel