Hi Alan,
> FreeRADIUS does this in the default install, and contains EAP tests
>(src/tests) for all major EAP types.
I actually went and re-read the RFC for PEAP. I noted that a server that
supports PEAP will reply with the highest supported version and the negotiation
will go from there. So it should not be a matter of having to configure eap
versus eap2. If I go with eap2 and get v1 working, it should support both v1
and v0. This is where I got confused, I missed the foot notes that PEAPv1 was
only available in the experimental build with the eap2 module.
> Don't use PEAPv1. It's even less documented than PEAPv0. It's used by
> pretty much no one.
This unfortunately is not by choice on my part. I am required to provide
lab setups for testing our products, based on what is in the product
requirement documents. This falls into what our product managers want to
support.
> Don't use LEAP. It's insecure. Don't put it into new products, and don't
> allow people to configure it.
As above, not really my choice, but I can't agree more. Fortunately this
protocol seems to be for legacy support. I have been and continue to make
recommendations to our product managers to remove support for unused and
unsecure protocols.
> Then the client is broken, and should be fixed.
The client is not falling back to PEAPv0 as one might expect, and when I
questioned the developers on this they told me it was working as designed.
They want to ensure that when it gets configured for a specific protocol, that
it fails unless it meets the requirements. Since our products go into
controlled install environments, they wanted to tighten up the authentication
requirements. Not robust, or quite following the RFC, but as designed. In
this case refer above as the client was expecting v1.
> Not really. By the time that the client has sent a PEAPv1 request, the EAP
> session has started. You can't switch EAP sessions from the "eap" module to
> the
> "eap2" module.
Again refer above, if I get eap2 module running with PEAPv1 support, it
should support both PEAPv0 and PEAPv1. I am assuming that configuring the eap2
module should replace the eap module with regards to protocols (ie. don't
configure a protocol in both only in one or the other). It is a matter of
getting FR setup to support a higher level of PEAP using the eap2 module. The
protocol should then negotiate to the lower protocol if the client requests
PEAPv0 instead of PEAPv1.
> Read eap.conf. Look for "gtc". This is documented. It works in the
> default install.
Noted. Also based on the RFC it was a miss-understanding of the protocols
by me. Once I re-read the RFC, I now understand that I was using GTC and
PEAPv1 interchangeably when I should not have been. GTC is available under
PEAPv0 and PEAPv1. I needed to refer to PEAPv1 not just GTC. Our product is
designed to use PEAPv1/GTC or PEAPv0/MSCHAP, and that was where I got confused.
Thanks for the info Alan. I will be working on the hostapd compile and
recompile of FR to support PEAPv1.
I hope that if anyone else stumbles across this thread they leave with a better
understanding of how PEAP is supported in FreeRADIUS, and how a PEAP
implementation should work with the client to negotiate the connection.
-Ward Hopeman
This message is intended only for the named recipient. If you are not the
intended recipient, you are notified that disclosing, copying, distributing or
taking any action based on the contents of this information is strictly
prohibited.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
