Re: [87attendees] IETF wireless

Stefan Winter <stefan.winter@restena.lu> Thu, 08 August 2013 06:35 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: 87attendees@ietfa.amsl.com
Delivered-To: 87attendees@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CC611E81A6 for <87attendees@ietfa.amsl.com>; Wed, 7 Aug 2013 23:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.512
X-Spam-Level:
X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=1.087, 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 35piCdMGrm6P for <87attendees@ietfa.amsl.com>; Wed, 7 Aug 2013 23:35:41 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 31AFA11E80F3 for <87attendees@ietf.org>; Wed, 7 Aug 2013 23:35:39 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id EE0D71058D for <87attendees@ietf.org>; Thu, 8 Aug 2013 08:35:37 +0200 (CEST)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id DFC5C1058B for <87attendees@ietf.org>; Thu, 8 Aug 2013 08:35:37 +0200 (CEST)
Message-ID: <52033C35.8060707@restena.lu>
Date: Thu, 08 Aug 2013 08:35:33 +0200
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: 87attendees@ietf.org
References: <767558DB-5546-4361-862E-0342F02AD435@ecs.soton.ac.uk> <EMEW3|a98bd69aea4959b1596d153ba8019962p74AmS03tjc|ecs.soton.ac.uk|767558DB-5546-4361-862E-0342F02AD435@ecs.soton.ac.uk> <alpine.OSX.2.01.1308050439080.146@173-11-110-132-sfba.hfc.comcastbusiness.net> <EB27A179-6515-43BE-B17B-2B853791788E@kumari.net> <alpine.DEB.2.02.1308080755220.5289@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1308080755220.5289@uplift.swm.pp.se>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="Nma20L5LfpQP396scwXG6s3CjKoxeoAVE"
X-Virus-Scanned: ClamAV
Subject: Re: [87attendees] IETF wireless
X-BeenThere: 87attendees@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <87attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/87attendees>, <mailto:87attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/87attendees>
List-Post: <mailto:87attendees@ietf.org>
List-Help: <mailto:87attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/87attendees>, <mailto:87attendees-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Aug 2013 06:36:02 -0000

Hi,

> Scary how many are using the unencrypted wifi.

Don't only count the ietf.1x network. The IETF also provides eduroam,
which is WPA2/AES with 802.1X and - sorry, NOC: actual server
certificate verification, not a "don't verify ours, and we won't verify
yours".

The Max numbers in the NOC report are

the 3 "secure" ones: 25+27+37 = 89
the two "edu" ones: 38 53 = 91

Which makes for a total of 180 max simultaneous encrypted connections.

Sure, compared to approx. 700 on the open networks it's not so really
great, but still quite a significant portion.

> A suggestion for next IETF would be to call the 802.1x wifi "IETF" and
> the open one "IETF_UNENCRYPTED".

Without verifying the server cert of the 802.1x network, you may well
talk to the network encryptedly, but the network might be a MitM who can
decrypt and snoop out your traffic.

The ietf.1x network is just not as good as it could be - maybe more
people would be inclined to use it if it provides the extra benefit of
being able to identify itself as *the genuine* IETF network. Neither the
open network nor the ietf.1x currently do that.

The fix would be surprisingly simple: in the Network Information page,
actually *publish* the CA cert and its fingerprint that signs the auth
server, and also publish the server's subject/subjectAltNames. This
allows every user to check whether he's on the real thing when connecting.

There are also provisioning tools that can install the CA certs and EAP
settings onto client devices. It's not rocket science.

Greetings,

Stefan Winter




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