EAP-TLS not successful

[Jouni Malinen]

On Thu, Jun 11, 2015 at 02:50:58PM -0700, Premraj Sundaram wrote:
> I was using JRadiusSimulator GUI as the client.
> The same client works with FreeRadius and returns Access-Accept.

That's strange if the test was done with same EAP-TLS fragmentation
behavior from the client.. If that worked, the server would need to
ignore incorrect TLS Message Length value (which, I'd assume, is
possible for FreeRADIUS to do, e.g., as an interoperability workaround;
I did not check its current implementation for this).

> I would prefer to make hostapd work, because my next step is to do EAP-AKA.
> 
> EAP: EAP entering state INTEGRITY_CHECK
> EAP: EAP entering state METHOD_RESPONSE
> SSL: Received packet(len=456) - Flags 0x00
> SSL: Received packet: Flags 0x0 Message Length 0
> SSL: Fragment overflow
> EAP-TLS: CONTINUE -> FAILURE
> 
> The above lines make me thinking whether it could be an SSL issue.

It is not; this is fragmentation issue in EAP-TLS, i.e., something that
happens before SSL (or well, TLS) processing. The test client is
claiming that the TLS Message Length is 1028 octets of which the first
1024 octets are included in the first message (the first fragment). That
would mean that the second fragment would need to include the remaining
4 octets. However, the second message includes about 434 octets which
hostapd is rejecting as invalid ("SSL: Fragment overflow") which is the
expected behavior with such a clearly incorrect fragmentation of an
EAP-TLS message.

-- 
Jouni Malinen                                            PGP id EFC895FA