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

[Olivier Beytrison]

On 18.07.2013 13:15, Phil Mayers wrote:
> On 18/07/13 12:02, Olivier Beytrison wrote:
> 
>> Sure we don't want that. But we could imagine a form of integration of
>> rlm_cache within eap. One of the benefit would be that we could save
>> attribute present in other lists (like control in my case). That way we
>> could work on those attributes in post-auth.
>>
>> Actually I need to put them in reply (in order for them to be saved),
>> and in post-auth I need to remove them (or through attr_filters).
> 
> So just write a suitable cache config and wrap it in a policy, then
> submit a patch?

That's already done on the IdP currently in production (also running 3.0
but from february/march). It works very well (using 3 different cache
modules for different needs/attributes).

Here this is, IMHO, a feature that is not working as expected.

I narrowed it down to why this happen now with EAP-PEAP/PEAP-MSCHAPv2 ...

in authorize, when eap (eap_peap) return "handled", the ldap module is
executed, and adds attributes to the reply.
It the goes to authenticate and EAP is called again, but only eap and
peap_mschapv2 are executed, not eap_peap.

so the fix would be to save the attributes in rlm_peap_mschapv2

Olivier

-- 

 Olivier Beytrison
 Network & Security Engineer, HES-SO Fribourg
 Mail: olivier at heliosnet.org