eap-ttls/mschapv2 versus eap-peap/mschapv2 behaviour
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 :
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 :
...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