In trying to be brief for the list, I realize now that I oversimplified my question.
What I am looking for a way to replace open, clear text WiFi at public hotspots (and possibly newly installed home WiFi routers) with something more secure. As you know, open WiFi presents security risks to the users and the operators. While WPA and WPA2 does provide for data-link encryption, it needs keying material to encrypt the communication. It can use a pre-shared key (PSK) for this purpose, but this has the drawbacks of communicating the key to the user and configuration on the end users part. Perhaps more seriously in a public access scenario it doesn't help, as you are giving the public the key which would by definition allow an attacker access to the keying material. That's where WPA-Enterprise comes in, with it's support for 802.1x and EAP. In "A secure Wireless LAN hotspot for anonymous users" (http://blogs.zdnet.com/Ou/?p=587), George Ou proposed that public access wireless operators could use WPA-Enterprise with PEAPv0/MSCHAPv2 and a well known username and password combination such as guest/guest. Because PEAP uses TLS, the keying material is sent securely from the RADIUS server to the client, even if the client side authentication is well known. The two downsides of this approach is similar to PSKs, in that you have to have a mechanism to communicate the configuration information, and the configuration is burdensome on the user. I have proposed this solution to hotspot operators whom, after testing, have rejected it as too difficult for the user. When thinking about George's proposed solution, I considered that WPA-Enterprise would be useful for these hotspots if we could use a EAP method that authenticates the identity of the server and provides for secure transfer of the keying material to the client without requiring the client to authenticate itself. RFC 5216 "The EAP-TLS Authentication Protocol" (http://www.ietf.org/rfc/rfc5216.txt) has clarified that it is not mandatory that the EAP server require peer authentication: "The certificate_request message is included when the server desires the peer to authenticate itself via public key. While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which peer authentication will not be needed (e.g., emergency services, as described in [UNAUTH]), or where the peer will authenticate via some other means." It seems that because the RFC does not require EAP-TLS to authenticate the client, it could provide that mechanism if there were a RADIUS server that supported EAP-TLS without client authentication. Obviously FreeRADIUS seems ideal for this purpose because of it's GPLv2 license, community support, and wide acceptance. Of course this will also rely on the popular 802.1x supplicants supporting the same. I plan on testing the client supplicant piece after setting up a server that can handle EAP-TLS without client certificate authentication. Hopefully it could be configured natively to do so, or with code changes if necessary. Thanks for your help! Christopher Byrd On Thu, Jan 8, 2009 at 4:00 AM, <t...@kalik.net> wrote: >>This may sound like a strange request, but I'd like to know if it is >>possible to use FreeRADIUS to perform EAP-TLS without asking for a >>client certificate. The purpose is to allow for a secure connection >>to an access point without client authentication. > > EAP has nothing to do with "secure connection to an access point". > That's what WPA is for. > > Ivan Kalik > Kalik Informatika ISP > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html