Release 1.1.1 TODO

[Alan DeKok]

Jouni Malinen <jkmaline at cc.hut.fi> wrote:
> The last time I looked at this compatibility layer, I did not find
> suitable functionality for implementing EAP methods due to the
> requirement of doing I/O with own routines (instead of using TCP
> sockets).

  Yuck.

> If someone is planning on converting FreeRADIUS to use GnuTLS, it might
> be worthwhile to take a look at the TLS wrapper I designed for
> wpa_supplicant (EAP peer) and hostapd (EAP server). It includes
> implementation for both OpenSSL and GnuTLS, i.e., there is a build time
> option to select which one to use and core code does not need any
> changes regardless of which TLS library is used. I would assume that
> similar design would work fine with FreeRADIUS, too, or at least
> tls_gnutls.c wrapper implementation can provide some examples on how
> EAP-TLS/PEAP/TTLS can be implemented with GnuTLS.

  Yeah.  I've taken a look at eapol_test.  It's *exactly* what we need
to do automated regression tests for FreeRADIUS.  It's also neat,
clear, and well designed.

  Do you think it would be a good idea to develop a client & server
EAP library?  I know FreeRADIUS has bits & pieces that have been
severely hacked over time.  FreeRADIUS also needs an EAP client
program that does more than radeapclient, and eapol_test doesn't send
RADIUS attributes.

  I had patches sitting somewhere for eapol_test that would link to
the FreeRADIUS libs & load the dictionaries.  Would you be interested
in those patches?

  Alan DeKok.