EAP-PEAP issues with session resumption disabled

[Jouni Malinen]

It looks like FreeRADIUS is currently checking whether session
resumption is enabled very late during EAP-PEAP negotiation. Even the
protected result indication for success is completed before FreeRADIUS
does this and sends EAP-Failure. However, at that point the client is
going to discard the EAP-Failure since the only allowed message after
successfully completed result indication is EAP-Success.

Would it be possible to move the session resumption enabled/disabled
check to be done much earlier during the process? Ideally, this would be
done when processing the TLS ClientHello so that server could just fall
back to using full authentication without causing authentication
problems. If that is not feasible for some reason, it would be useful
for the protected result indication to result in Failure, not Success,
so that the peer implementation would actually accept the EAP-Failure in
the end.

The code that triggers the current behavior is in eap_tls.c,
eaptls_success(). Debug log shows this:

[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
[peap] eaptls_verify returned 7 
[peap] Done initial handshake
[peap] eaptls_process returned 7 
[peap] EAPTLS_OK
[peap] Session established.  Decoding tunneled attributes.
[peap] Received EAP-TLV response.
[peap] Success
[peap] FAIL: Forcibly stopping session resumption as it is not allowed.

The EAP-TLV there was the end of the protected result (Success)
indication.

-- 
Jouni Malinen                                            PGP id EFC895FA