From jsalowey@cisco.com Tue Apr 2 14:25:32 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F00B21F8C69 for ; Tue, 2 Apr 2013 14:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UDUs-KcRGlF for ; Tue, 2 Apr 2013 14:25:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B77DD21F8C5B for ; Tue, 2 Apr 2013 14:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=223; q=dns/txt; s=iport; t=1364937931; x=1366147531; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=VpG9KdsNs+UzYrdQY4+KBahoLpRsomfkmSbggGiucM8=; b=h2ncfW3NgdqOcHdTot920+puqA/c4+vUrsIaQgl8bkN2AfeVCPKLGjGi D7INHVfsH0AXZLzWmla88OKj9TG6QLQwOkXwb1iMh5SYudX6VW6VNeqeU GkShHflWY9dhGaFVgT4xX9l0t28C5AbfzihvFIzEC7zolOr0Ti+dAti+n I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFALBLW1GtJXG9/2dsb2JhbABDgwfAKIEIFnSCIQEEOlEBKhRCJwQbiAygX5ESkAmOaIMXYQOndoMLgig X-IronPort-AV: E=Sophos;i="4.87,394,1363132800"; d="scan'208";a="194230184" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 02 Apr 2013 21:25:31 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r32LPVxa023865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Apr 2013 21:25:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 16:25:31 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: draft-ietf-emu-eap-tunnel-method-06 Thread-Index: AQHOL+ia8ntIgTp8hECRLlex5Txq9w== Date: Tue, 2 Apr 2013 21:25:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.151] Content-Type: text/plain; charset="us-ascii" Content-ID: <7832A3E2570FF54E84F15278E9C5E5C7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] draft-ietf-emu-eap-tunnel-method-06 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:25:32 -0000 We recently submitted a new revision of draft-ietf-emu-eap-tunnel-method-06= that we believe resolves the comments received during Working group last c= all. We believe it is ready to go to the IESG. Thanks, Joe= From johnsonhammond2@hushmail.com Sat Apr 27 10:02:39 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A66121F9840 for ; Sat, 27 Apr 2013 10:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwTEeoMkA3ef for ; Sat, 27 Apr 2013 10:02:38 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 058FC21F983B for ; Sat, 27 Apr 2013 10:02:36 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id CABFA3055F for ; Sat, 27 Apr 2013 17:02:14 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:02:14 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 918AA14DBDE; Sat, 27 Apr 2013 17:02:14 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:02:14 -0400 To: emu@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170214.918AA14DBDE@smtp.hushmail.com> Subject: [Emu] Biggest Fake Conference in Computer Science X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:15:23 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From stefan.winter@restena.lu Mon Apr 29 07:13:11 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E067121F9402; Mon, 29 Apr 2013 07:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.916 X-Spam-Level: X-Spam-Status: No, score=0.916 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_45=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6Qb3lcZ-oiz; Mon, 29 Apr 2013 07:13:10 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1112F21F99FB; Mon, 29 Apr 2013 07:13:10 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 977621057F; Mon, 29 Apr 2013 16:13:08 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 87B5D1057D; Mon, 29 Apr 2013 16:13:08 +0200 (CEST) Message-ID: <517E7FF4.1050009@restena.lu> Date: Mon, 29 Apr 2013 16:13:08 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "" , "radext@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CQMXGCKNDSRLOOIDTTDG" X-Virus-Scanned: ClamAV Subject: [Emu] Improving EAP usability and deployment security: call for participants X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 14:13:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CQMXGCKNDSRLOOIDTTDG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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.winter@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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2CQMXGCKNDSRLOOIDTTDG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF+f/QACgkQ+jm90f8eFWY/XQCgi+UhPzF8L2cfl61x3Pm4xEzo 2doAnjyaJBe77iGUOXn280VHt3hrMZUE =VWVd -----END PGP SIGNATURE----- ------enig2CQMXGCKNDSRLOOIDTTDG--