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: https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_... ...then restore them somewhere here; https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_... 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.