eapol_test, MSCHAPv2 and E=691,R=1

[Stefan Winter]

Hi,

apologies for the cryptic Subject :-)

We use eapol_test to do some extensive error condition checking on
eduroam RADIUS/EAP servers.

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 :-)

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

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.

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.

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).

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R?seau T?l?informatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x8A39DC66.asc
Type: application/pgp-keys
Size: 3243 bytes
Desc: not available
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20140401/c09261ba/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20140401/c09261ba/attachment-0001.pgp>