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; stefan.win...@restena.lu ). 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
