Michael Griego wrote:
It *is* supported by the Windows supplicant, and I'm pretty sure it wouldn't be that difficult to enable support in FR (removing one or two lines, IIRC).
I tried doing that a while ago. The immediate issue seemed to be that once the outer TLS tunnel was set up, the inner tunnel was negotiated... sort of. The inner tunnel got to the point where the client was sending a TLS "ack", asking for more data from the server. The problem was that it *wasn't* sending a TLS ack inside of the tunnel. Instead, it sent an empty TLS ack on the *outside* of the tunnel. This confused the code, as it believed that the outer tunnel was already set up, and it didn't know why the heck the client was asking for more data. So... to fix that requires more testing, and more code.
EAP-TLS inside of PEAP allows for the inner ("real") identity exchange to be obfuscated inside the tunnel since the outer identity doesn't have to match the inner identity. I've never used the PEAP-EAP-TLS functionality before myself in Windows, but if its anything like the PEAP-EAP-MSCHAPv2 support, this argument doesn't really mean anything since the inner and outer identities are both set to the real identity in the Windows supplicant...
Yup. I would prefer to use EAP-TTLS instead. It provides for differing inner/outer identities, and is a whole lot easier to deal with. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog