Re: [87attendees] IETF wireless

Stefan Winter <stefan.winter@restena.lu> Fri, 09 August 2013 06:03 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 0BBD821F9D2C for <87attendees@ietfa.amsl.com>; Thu, 8 Aug 2013 23:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level:
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 UhHlNgI7nNh3 for <87attendees@ietfa.amsl.com>; Thu, 8 Aug 2013 23:03:02 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CCD1D21F9CCC for <87attendees@ietf.org>; Thu, 8 Aug 2013 23:03:01 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 320961058D for <87attendees@ietf.org>; Fri, 9 Aug 2013 08:03:01 +0200 (CEST)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id C43B11058C for <87attendees@ietf.org>; Fri, 9 Aug 2013 08:03:00 +0200 (CEST)
Message-ID: <52048614.5000706@restena.lu>
Date: Fri, 09 Aug 2013 08:03:00 +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: <CE290E62.1F245%dharkins@arubanetworks.com>
In-Reply-To: <CE290E62.1F245%dharkins@arubanetworks.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="QbHjvkn3a7mU1S3aJFeMLPqsavQAkMtSd"
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: Fri, 09 Aug 2013 06:03:03 -0000

Hi,

>   Trust stores... CA bootstrapping.... Maybe we should get some
> authentication scheme on the ietf.1x network that doesn't require using
> certificates. Maybe RFC 5931 :-) There's none of that "inner method"
> nonsense, no need to select a CA, no real identity versus anonymous
> identity issues.
> 
>   I certainly would not mind eating that brand of dog food.

Nice advertising ;-)

Sure, EAP-pwd is a very interesting EAP method because it's simple AND
secure. We've made our eduroam IdP admins aware of it, and hope to see
it being used in eduroam, too.
There are some downsides in real deployment; e.g. if you have a
Microsoft AD, EAP-pwd won't get a representation of the password and
can't operate. So it's not for everybody.

But everybody who *can* make use of it should seriously consider it!

Thinking of this (sorry to ruin your ad): for the IETF it would not be a
clear winner: the mutual authentication is based on only you and your
auth server knowing your password.

For ietf.1x, I believe in most meeting incarnations, the username is
"ietf" and password "ietf"? In that case, any MitM can pretend to be
your EAP server. The server-side auth sort of breaks down if passwords
aren't secret. Server-side auth with CA and CN still survives in such
situations.

Greetings,

Stefan

> 
>   Dan.
> 
>> In eduroam, we *require* IdPs to "publish all information needed to
>> uniquely identify the authentication server"; and we even have an
>> automated provisioning tool which sets up supplicants with all the
>> correct and secure settings - including the CA installation.
>>
>> It works everywhere except on Karen O'Donoghue's Mac. ;-)
>>
>> Greetings,
>>
>> Stefan Winter
>>
>>>
>>> Chris.
>>>
>>>
>>> On Thu, Aug 8, 2013 at 2:35 AM, Stefan Winter <stefan.winter@restena.lu
>>> <mailto:stefan.winter@restena.lu>> wrote:
>>>
>>>     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 <tel:%2B352%20424409%201>
>>>     Fax: +352 422473 <tel:%2B352%20422473>
>>>
>>>
>>>     _______________________________________________
>>>     87attendees mailing list
>>>     87attendees@ietf.org <mailto:87attendees@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/87attendees
>>>
>>>
>>>
>>>
>>> -- 
>>> Chris Elliott
>>> chelliot@pobox.com <mailto:chelliot@pobox.com>
>>
>>
>> -- 
>> 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
>>
> 
> _______________________________________________
> 87attendees mailing list
> 87attendees@ietf.org
> https://www.ietf.org/mailman/listinfo/87attendees
> 


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