EAP-TLS without client authentication

[Alan DeKok]

Christopher Byrd wrote:
> 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.

  This is network layer security.

>  That's where WPA-Enterprise comes in, with it's
> support for 802.1x and EAP.

  Yes.  EAP provides keying material.

> 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.

  That's marketing nonsense.  Don't believe random garbage you read on
industry web sites.

> 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.

  I spend a fair amount of time working with WiFi operators &&
telecommunications companies.  None of them will do EAP unless it's easy
for their end users.

> 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:

  Ignore George's blog.  It's marketing material.  It has little to no
relevance for operators running real networks.

> "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."

  Emergency services are being removed from many network access
standards.  That use is being abused, and isn't useful.

> It seems that because the RFC does not require EAP-TLS to authenticate
> the client,

  It does.  The only time the client isn't being authenticated is via
mechanisms that aren't implement, aren't supported, and are being
deprecated.

> 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.

   Operators will not agree to this.

> 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.

  Supplicants do not currently support this.  I know all of the major
supplicant vendors, and I doubt very much this functionality will go in.

  Perhaps you could describe what the *problem* is in more detail.
Talking about specific solutions often results in the discussion getting
bogged down in details about why it won't work that way.

  As background, many operators are looking into moving to 802.1x
everywhere.  If it's supported on their home networks, then their users
will have it configured, and it will (usually) work on visited networks,
too.

  Alan DeKok.