Re: Admission Control to the IETF 78 and IETF 79 Networks

Russ Housley <housley@vigilsec.com> Fri, 02 July 2010 01:19 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849763A67EF for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 18:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.441
X-Spam-Level:
X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9odt7E1BA4e for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 18:19:37 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 2F3613A6803 for <ietf@ietf.org>; Thu, 1 Jul 2010 18:19:37 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8868F9A473C for <ietf@ietf.org>; Thu, 1 Jul 2010 21:19:42 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 3Z7Jwy+PvSa8 for <ietf@ietf.org>; Thu, 1 Jul 2010 21:19:35 -0400 (EDT)
Received: from [192.168.2.108] (pool-96-241-163-123.washdc.fios.verizon.net [96.241.163.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CF3DF9A4724 for <ietf@ietf.org>; Thu, 1 Jul 2010 21:19:41 -0400 (EDT)
Message-ID: <4C2D3EAC.6060907@vigilsec.com>
Date: Thu, 01 Jul 2010 21:19:40 -0400
From: Russ Housley <housley@vigilsec.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
References: <CFB08C07-DE90-47BE-ADFF-FC72162BBFA1@daedelus.com> <4C2BBD51.2060605@ietf.org> <6.2.5.6.2.20100701070804.0c26b8a0@resistor.net> <6D6E25E2-057B-4591-9288-1283036D0374@cisco.com> <4C2CB739.4030101@dcrocker.net> <700E34E1-6B18-4D6E-B0C5-DC98174C45C9@bbn.com> <AANLkTinDMVXzw04aJFnoxqrnV5BZ9XCa73Z0hzZ0J57k@mail.gmail.com>
In-Reply-To: <AANLkTinDMVXzw04aJFnoxqrnV5BZ9XCa73Z0hzZ0J57k@mail.gmail.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 02 Jul 2010 01:19:38 -0000

Ted:

>> There's a difference, however, between ticking a box and having individual
>> user-attributable credentials.  The two techniques are focused on different
>> goals, generically binding users to an AUP, without caring who they are,
>> versus being able to identify individual users on the network (with more
>> detail than a MAC address).
>>
>> The proposal here is the latter, which would seem to raise the question of
>> why individual user attribution is necessary, i.e., why anonymity in the
>> IETF network unacceptable -- even within the pool of IETF participants.
> 
> I agree with Richard's view here, and I suggest the following
> modifications to the  proposed admission control:
> 
> 1) Use only paper-provided slips to provide authentication credentials.
> There is no stated reason for associating specific registration data
> with the network authentication method and it is trivial to provide
> the slips of paper to anyone with a proper badge.  Let the individual
> getting a slip shuffle the pile, get multiple slips every day, or do
> whatever else they would like to increase randomness.  But start from
> the presumption that the admission control is to limit access to
> "registered attendees only" not to provide an association to
> registration data.
> 
> 2) Favor anonymous MAC registration over portal methods.  Set up a
> terminal or group of terminals which allow individuals to register
> their MAC addresses for access.   Allow anyone with a badge access to
> those terminals, and do not collect information on which individual
> entered which MAC address.  (The portal mechanism relies on a specific
> ordering of application protocol activity at best; at worst it
> provides a full-on monkey-in-the-middle.  That should be a last
> resort)
> 
> 3) For the portal, there is no reason to have the MAC-based
> permissions created to be time limited.  If proper credentials from a
> slip of paper are entered, there is no reason not to treat this as
> equivalent to registration of the MAC address for the duration of the
> meeting.
> 
>  My personal preference is that this requirement from the host be
> politely declined as contrary to the usual operation of the IETF
> network.   But if it is not going to be declined, then the admission
> control should not further the ability to associate specific
> credentials to individuals.

A few points in response:

1) Anonymous slips are available to anyone with an IETF meeting badge
that wants them, as often as they want them, from two sources: the IETF
registration desk and the network help desk.

2) The MAC address registration is available at the network help desk.

3) I have not discussed the portal time limit with the NOC Team, but
I'll recommend that the registration work for the whole week.

Russ