Jouni Malinen <jkmaline@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.