Re: addition to policy.conf
One other thing, I would like this to be in the standard distribution so sites can just enable it with one line, however, we in UK will provide a local policy in addition which will capture the common UK realm problems we see (mainly derived from typos) and match our local UK technical specification...I also wanted a generic ruleset that could be acceptable rather than labelling/tagging it as eg 'eduroam' alan
Alan Buxey wrote:
One other thing, I would like this to be in the standard distribution so sites can just enable it with one line, however, we in UK will provide a local policy in addition which will capture the common UK realm problems we see (mainly derived from typos) and match our local UK technical specification...I also wanted a generic ruleset that could be acceptable rather than labelling/tagging it as eg 'eduroam'
I'll push something to v2.1.x Alan DeKok.
hi, during recent testing/validation of authentication methods on our server we found a problem with EAP-TTLS/EAP-MSCHAPv2 basically, after looking at the packets to see whats wrong or where things went wrong we found the following to be the case, the inner-tunnel calls the EAP-MSCHAPv2 method which itself is an EAP method.. the end result is two sets of some MS-MMPE keys MS-MPPE-Send-Key MS-MPPE-Recv-Key these get duplicated.... our current 'fix' is to just reset these in the post-auth section of the inner-tunnel so that only the last ones are created/dealt with - so far, that works for clients but its a little ugly and shouldnt be needed. post-auth { # # Remove the Double Sets of Keys when using ttls eap in eap # update reply { MS-MPPE-Send-Key !* 0x00 MS-MPPE-Recv-Key !* 0x00 } } can anyone else validate this behaviour (in case its resulting from something we've done)? alan
On 26/06/12 10:53, alan buxey wrote:
can anyone else validate this behaviour (in case its resulting from something we've done)?
Which version of the server? I thought there was code in the EAP-TTLS and EAP-PEAP modules which specifically handled this, and removed the MPPE keys from the inner reply.
alan buxey wrote:
during recent testing/validation of authentication methods on our server we found a problem with EAP-TTLS/EAP-MSCHAPv2
basically, after looking at the packets to see whats wrong or where things went wrong we found the following to be the case,
the inner-tunnel calls the EAP-MSCHAPv2 method which itself is an EAP method.. the end result is two sets of some MS-MMPE keys .. can anyone else validate this behaviour (in case its resulting from something we've done)?
It works for me with the current "git" head. Maybe there's something different about the client? The only thing I can see which *might* help is: rlm_eap_mschap.c: case PW_EAP_MSCHAPV2_SUCCESS: eap_ds->request->code = PW_EAP_SUCCESS; pairadd(&handler->request->reply->vps, data->mppe_keys); data->mppe_keys = NULL; /* fall through... */ It could be: case PW_EAP_MSCHAPV2_SUCCESS: eap_ds->request->code = PW_EAP_SUCCESS; if (!handler->request->parent) { pairadd(&handler->request->reply->vps, data->mppe_keys); data->mppe_keys = NULL; } /* fall through... */ That might work. Alan DeKok.
Hi,
It works for me with the current "git" head. Maybe there's something different about the client?
fussy client - eapol_test/wpa_supplicant ;-)
The only thing I can see which *might* help is: rlm_eap_mschap.c:
that *appears* to do the work nicely. our local config change is commented out and we now get SUCCESS alan
participants (4)
-
Alan Buxey -
alan buxey
-
Alan DeKok -
Phil Mayers