eapol_test, MSCHAPv2 and E=691,R=1
j at w1.fi
Sun Feb 1 10:56:29 EST 2015
On Tue, Apr 01, 2014 at 08:50:34AM +0200, Stefan Winter wrote:
> I have recently encountered a condition where the remote RADIUS server
> behaves correctly, but eapol_test does its best to make me believe it's
> not :-)
Well.. If you had wpa_cli or some other tool listening on the control
interface, you'd see much more clearly what's happening here..
> The issue comes when authenticating with PEAP-MSCHAPv2, supplying a
> *wrong* password in the wpa_supplicant.conf settings, and having a
> server on the other end which is configured to support MSCHAPv2 retries.
> The exact problematic behaviour is this:
> * ... EAP session setup with TLS as normal
> * ... MSCHAP-Challenge sent, wrong response from eapol_test
> * RADIUS/EAP server sends an *Access-Challenge* with E=691,R=1
> (authentication failure, retry allowed)
> * eapol_test does not send the password again; but also does not send
> anything else
> * eapol_test bails out after timeout
eapol_test requests user to re-enter username/password at this point in
time and wait for that response (or a request to disconnect if user does
not want to try another username/password).
> For scripts which expect a proper RADIUS conversation termination, this
> looks extremely fishy: the last incoming packet was a a Challenge, so
> the server never finished the EAP state machine properly.
> I am wondering how to do this better; MSCHAPv2 doesn't have a response
> by the client along the lines of "Thank you for allowing me to retry,
> but I'd rather not - Goodbye". So I'm somewhat sympathetic for
> eapol_test to just remain silent.
That is not the reason for eapol_test behavior; the reason for it is
that it does actually support password retry. Your specific use case
just does not happen to have any tool above eapol_test to allow this to
be indicated to the user. As can be seen in the R=0 case, wpa_supplicant
does have a message to send (EAP MS-CHAPv2 Failure Response). That same
message can be sent with R=1 if the peer does not want to retry.
> however: couldn't eapol_test just send a TLS Close/Alert in response,
> thus requesting the outer EAP to be torn down? This would very probably
> trigger an Access-Reject from the server, and all is fine.
Sending EAP MS-CHAPv2 Failure Response should be fine for this use case.
> Alternatively, if it really sends nothing, could it return to the
> command-line immediately instead? Waiting for the timeout is of no real
> use here; both ends have stopped talking to each other, so there is
> nothing that could resolve the situation anyway. Going back to the
> command-line with FAILURE immediately would have the benefit of working
> time measurements that check the duration of the EAP conversation
> (something we also do).
I added a new option ("mschapv2_retry=0" in phase2) that can be used to
disable support for MSCHAPv2 password retry. In other words, if that is
added to the phase2 value, wpa_supplicant will indicate failure on any
E=691 case regardless of R=<0/1> value.
Jouni Malinen PGP id EFC895FA
More information about the HostAP