Subject: [radext] Improving EAP usability and deployment security: call for participants

From: Stefan Winter <[email-masked]>
Date: Mon, 29 Apr 2013 16:13:08 +0200

Hello,

(and sorry for being slightly off-topic)

I'm writing this mail as someone who is heavily involved with deploying
Enterprise WiFi to millions of end users, belonging to thousands of
independent administrative domains, all of which have their own EAP
deployment and associated supplicant configuration needs - the eduroam
roaming consortium (you may want to look at
http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-00
for a description of the consortium and its inner workings).

Over the ten years of operation of eduroam, we have seen the good, the
bad, and the ugly of supplicants, and realised that even if there are
excellent technical specifications (IEEE 802.11i, IEEE 802.1X, EAP,
various EAP types, RADIUS, ...), the real world deployments of these
specifications aren't always as perfect as they should be.

One of the biggest complaints we hear from end users is the effort of
initial supplicant setup, and sometimes the sad fact that users are
either DoSed because their device doesn't support any EAP type which
matches their organisation's deployment; or that the supplicant setup is
only possible with leaving gaping security holes open (e.g. not possible
to specify which CA issued the EAP server certificate!).

We believe that there is a lot of potential in the implementation space
to take EAP peers - 802.1X supplicants - to a new level of
a) implementation completeness
b) user-friendly interactive configuration
c) automated configuration deployment (a.k.a. "profiles")

There is currently a call for participants in a European project where
one of the topics on call is "IEEE 802.1X and EAP - Improving
Implementation Completeness and User-Friendliness". It's call #16 of the
list on this page:

http://www.geant.net/opencalls -> "Call Text"

My employer and other organisations are in the process of forming a
consortium to reply to this call and we are looking for further partners
- in particular industry partners who implement supplicants and ship
them in their products; the main goals of the consortium-to-be is to
develop guidelines for UI design, cornerstones for implementation of EAP
in supplicants, and a standard interface for conveying EAP configuration
data ("EAP metadata") to the supplicants for automatic configuration
provisioning - and of course to have partners who are willing to
implement these guidelines!

Why should you join? The benefit for you as a supplicant implementor to
join the project is that you'll get valuable input and suggestions for
improving your product - which will ultimately give you an advantage on
the market compared to other implementations which don't participate.
The time your workforce spends in this project will be partially
compensated for according to normal European Commission project rules
(I'm not a finance guy, so just as a non-authoritative indication: with
exceptions, only European entities can be compensated; up to a maximum
of 50%-75% of the workforce expenditure plus overhead (subject to
several conditions)).
The slide deck of the "Information Day" regarding this call which was
held on 19 April may give you more specific detail; slide 54 f. are
about this particular objective. Also check out the FAQ!

http://www.geant.net/opencalls -> "Information Day"
http://www.geant.net/opencalls -> "FAQ"

If you or your company are interested in joining this consortium, please
get in touch with me (off-list; [email-masked] ). Note that
while I'm recruiting for this project-to-be, my company will very likely
not take the consortium leadership role but be a mere member of the
consortium.

Thanks for your attention! For those who care, a number of real-life
imperfections is below.

Greetings,

Stefan Winter

There are numerous examples of imperfection; I do not believe that a
single perfect supplicant exists. So, when I give a few examples below
please understand them as random specimen of the world out there, not as
a particular name&shame for the company names in these examples. It just
goes to show that there is work in this for everyone :-)

Example 1: EAP identity has a 1:1 mapping with an SSID
======================================================
Apple, Inc. has a very powerful tool for deployment of WiFi
configuration profiles to recent Mac devices and i* mobile devices using
their "mobileconfig" file format. Unfortunately, the file format assumes
that the SSID is the primary discriminator of networks, and that an EAP
identity is a property of an SSID. As a consequence, if an Enterprise
WiFi deployment uses multiple SSIDs, all to be used with the same EAP
identity, these need to be configured independently. This is not just a
question of deployer's convenience when crafting the config files: it
transpires down to the end user, who has to enter his username and
password "n" times while installing the profile, once for each SSID in
the set - even if the account information is identical.

This approach also makes uses in the new Hotspot 2.0 / IEEE 802.11
Interworking difficult. An automated configuration file format should
have the richness to define an EAP identity, and in a 1:n mapping any
number and form of applicable uses for this EAP identity; sth like "This
EAP identity is good for the SSIDs 'ietf-1x', 'ietf-1x-11n', all
networks of the consortium "ca:fe:ba:be", the wired 802.1X network with
the network ID 'foo' and for all ABFAB uses". Devices consuming this
configuration should only ask for and store the user credentials /once/
and use them for all defined use cases automatically.

Example 2: Mutual Authentication doesn't verify exact server identity
=====================================================================
Google, Inc.'s Android operating system supplicant allows a user to
specify the CA which the EAP server's server certificate has to be
issued from. It does not allow to specify the Subject of the expected
incoming certificate. If the EAP server has a certificate which is
issued from a large ("commercial") CA, an attacker can request an
unrelated certificate from the same CA, set up a fake EAP server and
trick the user to connect to the associated network. The supplicant will
not be able to detect that the server is not his proper EAP server, and
will release the user credentials to that unauthorised server.

Example 3: Mutual Authentication not possible
=============================================
Microsoft, Inc. has various implementations of EAP for various
platforms. One of those is Windows Phone 7, which supports EAP (at least
EAP type PEAP). Technically, an EAP conversation with mutual
authentication is carried out (i.e. the supplicant requires the server
to send a server certificate prior to releasing the client credentials);
but the device does not allow to specify which server certificate from
which CA to expect. As a consequence, arbitrary third parties can craft
their own CA and server certificate and present this; or have a
commercial CA issue a unrelated certificate for them - and the client
credentials are released to these third parties. Windows Phone 8 has
become better (as bad as Example 2) by adding the possibility to add the
CA certificate validation but as in the case of Example 2, there is no
place for server identity verification.

Example 4: Suboptimal User Interface
===================================
The K Desktop Environment's user interface for WiFi configuration,
KNetworkManager, mixes user authentication details and server-side
authentication details into one single dialog with no clear distinction.
E.g. when selecting using EAP-TLS, there is one single list of visual
elements for user(U) and server-side(S) details like
(U) Identity
(U) User Certificate
(S) Server Certificate
(S) Use System CA certificates
(S) Connect to these Servers
(U) Private Key
(U) Private Key Password

The "System CA" checkbox for server-side credential checks is also
dangerous by making the connection insecure - more than the exact one CA
to be trusted would be permitted then. Offering such an option is
counter-productive.
Supplicants should give a clear indication that mutual authentication is
taking place, and should separate user authentication from server
authentication UI elements for clarity when configuring interactively.

Example 5: Unhelpful advice on failed authentications
=====================================================
In case of an unsuccessful authentication, many supplicants disregard
the exact state of the EAP state machine and simply convey a simplistic
error message to the user: "Probably your password was wrong." An ideal
EAP implementation would examine the state machine, and depending on the
moment the failure occured give accurate advice to the user. E.g.: If
the the initial EAP-Response/Identity was sent, but no reply ever came
back, then the error is unrelated to the user's password; no EAP
conversation was established with the other end even. A useful error
message in this case would be "Unable to contact the authentication
server. Please try again later, or check your username."

Example 6: no EAP support on WiFi interface
===========================================
There are also end-user computing devices which allow to connect to
WiFi, but do not support EAP authentication / 802.11i Enterprise at all.
One recent example is FirefoxOS, which does not currently allow users to
log into enterprise WiFi networks.

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473