On 09/26/2012 10:18 PM, Alan DeKok wrote:

It's gathered enough questions recently that I think we're better off deleting it.

+1 Or at very least, breaking it out into a separate github repo, which should serve to convince people it's not "core" - maybe one of the people who so desparately needs it can maintain it ;o) I've been hassling people who use it as to which EAP method they need that's missing. A couple of them have been eap-psk (anyone know why the sudden interest in that?). I've got a 5000 word assignment to finish at the moment, but once that's done, I'm going to have a crack at just writing a native rlm_eap_psk - it doesn't look hard.

On 27/09/12 09:37, alan buxey wrote:

Hi,

...

I've been hassling people who use it as to which EAP method they need that's missing. A couple of them have been eap-psk (anyone know why the sudden interest in that?). I've got a 5000 word assignment

some student project?

Yeah, I'm doing a 2nd degree in my spare time - broaden my horizons, eat up all my spare time, make me grit my teeth, etc. ;o)

the current thing that holds interest for me is EAP-FAST - and therefore, in the future EAP-FASTv2 - aka EAP-TEAP

EAP-FAST is currently the mechanism buried inside Ciscos MACSEC TrustSec

FAST and TEAP are a bit... thorny. I guess in response to how horrible LEAP was, they've layered on a *lot* of stuff in there - multiple per-inner-exchange crypto (re)binding, and the PAC stuff. It's not entirely clear to me that OpenSSL provides the required APIs to do everything that FAST/TEAP can on the server-side, but I think so, largely as a result of Jouni Malinen hassling the OpenSSL guys to take his patches: http://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=1574 ...although the sheer amount of *time* that took concerns me; if there's a missing API it'll be *forever* before it's corrected. I'd like to implement TEAP, if only because it's a good tickbox. I'm less keen on FAST, since it's been theoretically superseded by TEAP, and unlike PEAP/TTLS, FAST was never widely adopted. If FAST is easy by re-using TEAP code, then that's good. w.r.t. FAST/TEAP there are a couple of things to sort out conceptually, specifically how to handle the support for multiple inner auths, and how to "signal" which order and what the required chaining is. Until I have a working prototype, it's difficult to wrap my head around. Anyway - when I get a github branch working I'll discuss on -devel. Unless someone beats me to it, which will make me happy ;o)