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

Phil Mayers p.mayers at imperial.ac.uk
Thu Jul 18 16:51:22 CEST 2013

On 18/07/13 14:59, Olivier Beytrison wrote:

> 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.
> And we get different behaviour on the server (okay they are two
> different eap types with different flows).

TTLS and PEAP are a red herring.

The issue is that MSCHAP is different to EAP-MSCHAPv2, and is processed 
in a single pass through the inner-tunnel virtual server - so of course, 
attributes from authorize are present in post-auth.

EAP-MSCHAPv2 is different, and is processed in 3 passes through the 
inner-tunnel (ident/challenge, response/success, success/ack). You are 
proposing to save attributes from pass 2, and restore them in pass 3, so 
that you can continue to take advantage of the short-circuit in pass 1/3.

If you were to use EAP-TTLS/EAP-MSCHAPv2, you would see the same 
behaviour as with EAP-PEAP/EAP-MSCHAPv2.

If you *must* fix this anywhere, the right place to fix it is in the 
EAP-MSCHAPv2 code. Save the attributes somewhere here:


...then restore them somewhere here;


However, I think you're underestimating how hard this is; to make the 
EAP-MSCHAPv2 case look like plain MSCHAP, you need to save request, 
control and reply attributes, and somehow merge them back in.

I think this is a complex enough decision that it should be kept out of 
the server core, and implemented with a cache/policy wrapper so people 
can modify it.

> Full debug of a eap-peap/mschapv2 :
> https://gist.github.com/olivierbeytrison/912b9aa8e0ebc3cc0385

Yes, note that request #6 (line 1610) #7 (line 1798) and #8 (line 2024) 
are *EAP*, and short-circuits happen in #6 and #8.

> full debug of an eap-ttls/mschapv2 :
> https://gist.github.com/olivierbeytrison/3ca76806d015ad108104

...whereas in this, request #7 (line 983) is plain MSCHAP (no EAP) and 
is the *only* request which goes to inner-tunnel.

More information about the Freeradius-Devel mailing list