eapol_test, MSCHAPv2 and E=691,R=1

[Jouni Malinen]

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