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
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to