FreeRADIUS EAP-TLS issues

Alan DeKok aland at deployingradius.com
Thu Nov 22 17:28:59 CET 2007


Jouni Malinen wrote:
> It looks like I can now receive the first fragment of the long phase 2
> message from the server. This is sent in two phase 1 fragments and the
> combined data can be decrypted correctly. However, after this, the
> server does not seem to be sending out the following data from phase 2.

  Yup.

> The phase 2 message (the one with EAP-TLS ServerHello, Certificate,
> ServerKeyExchange, and CertificateRequest) is 3808 bytes and it looks
> like only the first 1020 bytes (fragment_size - 4 octets for TLS Message
> Length field) is transmitted. Is the phase 2 data actually truncated
> somewhere?

  No.  From what I've seen in the debug output, the issue is that
there's an out TLS ACK message where (perhaps naively) I would expect
outer encrypted data, inner tunnel TLS ACK for the next fragment.

  FreeRADIUS remembers the EAP sessions internally, along with what it
expects to see "next".  The implementation choice is that the inner
tunnel EAP Id's are faked out by copying the outer tunnel ones.  So if
the inner tunnel isn't called for an ACK, the Id's "skip" one number,
and the code gets excited that it can't find a matching Id.

  The explanation is complicated...

...
> However, this would require the larger server message to go through
> which is something I do not see. Could you please send me the hacks
> needed to get here?

  Attached.  In short, the sessions are matched only by the State
attribute, and it ignores EAP Id's.

  This is arguably the correct thing to do anyways...

  Alan DeKok.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jouni.patch
Type: text/x-patch
Size: 1447 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20071122/aa8e98db/attachment.bin>


More information about the Freeradius-Devel mailing list