Re: Security for the IETF wireless network

joel jaeggli <joelja@bogus.com> Fri, 25 July 2014 12:30 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF3F1B2801; Fri, 25 Jul 2014 05:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiKPcMigDq8T; Fri, 25 Jul 2014 05:30:32 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF751B2831; Fri, 25 Jul 2014 05:30:31 -0700 (PDT)
Received: from dhcp-a112.meeting.ietf.org (dhcp-a112.meeting.ietf.org [31.133.161.18]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s6PCUTtT020504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Jul 2014 12:30:30 GMT (envelope-from joelja@bogus.com)
Message-ID: <53D24DE4.1030107@bogus.com>
Date: Fri, 25 Jul 2014 08:30:28 -0400
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0
MIME-Version: 1.0
To: "George, Wes" <wesley.george@twcable.com>, "ietf@ietf.org" <ietf@ietf.org>, IETF Chair <chair@ietf.org>
Subject: Re: Security for the IETF wireless network
References: <0FE63216-9BE8-450F-80FB-D1DB6166DFEF@ietf.org> <CFF7BBD1.28A2F%wesley.george@twcable.com>
In-Reply-To: <CFF7BBD1.28A2F%wesley.george@twcable.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="67ScWx7In0GhBd8BVNTnh7MLgkx4nc1dp"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 25 Jul 2014 12:30:30 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/KURu04UXCX17B8ch5YR4tNqBfUA
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jul 2014 12:30:36 -0000

On 7/25/14, 7:59 AM, George, Wes wrote:
> Jari, while I support this idea, if I had to prioritize, I'd rather us
> focus on consistently offering *any* secured WiFi option in the hotel
> rooms.
> 
> Here at the Fairmont, for example: ietf-hotel is the only SSID available,
> and it's not secure. Yes, one could use wired, assuming one's widget has
> an ethernet plug, but many now don't.

If you have the luxury of a wired port, deploying your own ap will
probably get you more deterministic service, and a secure air interface.
prefix delegatation is probably  something we need to do.

The amount of control we have over the hotels infrastruture varies, this
time it's a meru controller and we were able to change the ssid and get
it to bridge ipv6 which are both tiny miracles.

> I realize that this request is often limited by the host hotel's
> infrastructure, which may or may not support .1x, but even if the best we
> can do is to offer WPA2 with "IETF", or "encryptionFTW" as the password,
> that'd be a great improvement over what we have currently.

We end up providing network service to the rest of hotel during the
meeting so it also needs to work as expected for the rest of the guests.

> Thanks,
> 
> Wes
> 
> 
> On 7/24/14, 4:38 PM, "IETF Chair" <chair@ietf.org> wrote:
> 
>> While many of us have been working on improved transport and other
>> security mechanisms, I’d like to observe that the default wireless
>> network we are using here in Toronto is unencrypted over the air.  I am
>> not sure how good practice that is. And it is probably not a good example
>> either.
>>
>> Could we consider making 802.1X the default, for instance, starting in
>> Honolulu meeting? At least in the sense of the ietf SSID providing
>> security and perhaps ietf-nosec providing the current behaviour?
>>
>> It would also be helpful if you try it now. The two SSIDs, ietf.1x and
>> ietf-a.1x are available now, we recommend you use them and we would
>> appreciate your reporting any problems. The user ID and password are both
>> 'ietf' (sans quotes).
>>
>> Jari Arkko
>> IETF Chair
>> (with input from some NOC people)
>>
> 
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
>