EAP-TLS without client authentication

[Christopher Byrd]

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. I think this might
be useful to replace "open wireless" for public wireless access with
something more secure.

According to the EAP-TLS RFC (rfc2716), it sounds like it might be possible:
"The certificate_request message is included when the server desires
the client to authenticate itself via public key. While the EAP server
SHOULD require client authentication, this is not a requirement, since
it may be possible that the server will require that the peer
authenticate via some other means."

I tried this with FreeRADIUS and eapol_test (from wpa_supplicant) with
the following result:

[eap] Identity does not match User-Name, setting from EAP Identity.
[eap] Failed in handler
++[eap] returns invalid
Failed to authenticate the user.

The only change I've made from the default eap.conf is to try
disabling the CA_file setting (I've tried it both ways).

Does it sound like this is something that should be possible, or am I off base?

Thanks!

Christopher
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[t***@kalik.net]

Post by Christopher Byrd
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

[Christopher Byrd]

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

Post by t***@kalik.net

Post by Christopher Byrd
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

[t***@kalik.net]

Post by Christopher Byrd
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.

So they don't want PSK.

Post by Christopher Byrd
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.

And configuring something that Microsoft calls Zero Configuration is too
complicated.

Use captive portal then.

Ivan Kalik
Kalik Informatika ISP

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok]

Post by Christopher Byrd
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.

Post by Christopher Byrd
That's where WPA-Enterprise comes in, with it's
support for 802.1x and EAP.

Yes. EAP provides keying material.

Post by Christopher Byrd
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.

Post by Christopher Byrd
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.

Post by Christopher Byrd
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

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

Post by Christopher Byrd
"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.

Post by Christopher Byrd
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.

Post by Christopher Byrd
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.

Post by Christopher Byrd
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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Hanno Schupp]

Hi,

Another approach you may wish to try is using the hotspot firmware on the
hotspot router to help you in conjunction with the freeradius server.
Coovachilli seems to have a solution, based on freeradius, jradius and
coovachilli (maintained branch of chillispot, as I understand). Have a look
here http://coova.org/wiki/index.php/CoovaChilli/WithWPACaptivePortal
whether that is what you are looking for.

Cheers

Hanno Schupp

-----Original Message-----
From: Alan DeKok [mailto:***@deployingradius.com]
Sent: Friday, 9 January 2009 10:00 a.m.
To: FreeRadius users mailing list
Subject: Re: EAP-TLS without client authentication

Post by Christopher Byrd
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.

Post by Christopher Byrd
That's where WPA-Enterprise comes in, with it's
support for 802.1x and EAP.

Yes. EAP provides keying material.

Post by Christopher Byrd
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.

Post by Christopher Byrd
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.

Post by Christopher Byrd
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

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

Post by Christopher Byrd
"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.

Post by Christopher Byrd
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.

Post by Christopher Byrd
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.

Post by Christopher Byrd
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.



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html