eap-ttls/mschapv2 versus eap-peap/mschapv2 behaviour

[Olivier Beytrison]

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
> data.
> 
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)

Olivier