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. >
- Re: Security for the IETF wireless network Brian E Carpenter
- Re: Security for the IETF wireless network Stefan Winter
- Re: Security for the IETF wireless network George, Wes
- Re: Security for the IETF wireless network George, Wes
- Hotel networks (Was Re: Security for the IETF wir… Steve Crocker
- Re: Security for the IETF wireless network joel jaeggli
- Re: [90all] Security for the IETF wireless network Randall Gellens
- Re: Security for the IETF wireless network Stefan Winter
- Re: Security for the IETF wireless network Tim Wicinski
- Re: [90all] Security for the IETF wireless network Randy Bush
- Re: Hotel networks (Was Re: Security for the IETF… John C Klensin
- Re: Hotel networks (Was Re: Security for the IETF… Steve Crocker
- Re: Hotel networks (Was Re: Security for the IETF… joel jaeggli
- Re: Hotel networks (Was Re: Security for the IETF… Steve Crocker
- Re: Hotel networks (Was Re: Security for the IETF… George Michaelson
- Re: Hotel networks (Was Re: Security for the IETF… John C Klensin
- Re: Hotel networks (Was Re: Security for the IETF… Stefan Winter
- Re: Security for the IETF wireless network Bill Fenner
- Re: Security for the IETF wireless network George Michaelson
- Re: Security for the IETF wireless network Stefan Winter
- Re: Security for the IETF wireless network Brian E Carpenter
- Re: Security for the IETF wireless network Bill Fenner
- Re: Security for the IETF wireless network Bill Fenner
- Re: Security for the IETF wireless network John Levine
- Re: Security for the IETF wireless network Stefan Winter
- Re: Security for the IETF wireless network Stefan Winter
- Re: Hotel networks (Was Re: Security for the IETF… Samuel Weiler
- Re: Hotel networks (Was Re: Security for the IETF… Randall Gellens
- Re: Hotel networks (Was Re: Security for the IETF… Randall Gellens
- Re: Hotel networks (Was Re: Security for the IETF… Niels Dettenbach (Syndicat IT&Internet)
- Re: Hotel networks (Was Re: Security for the IETF… Stefan Winter
- Re: Hotel networks (Was Re: Security for the IETF… Randall Gellens
- Re: Hotel networks (Was Re: Security for the IETF… Randall Gellens
- Re: Hotel networks (Was Re: Security for the IETF… Melinda Shore
- Re: Security for the IETF wireless network Michael Richardson