Test Environment: Can PEAPv0 and PEAPv1 be setup together on the default instance?

[Hopeman, Ward]

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.