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

Ted Hardie <ted.ietf@gmail.com> Thu, 01 July 2010 17:49 UTC

Return-Path: <ted.ietf@gmail.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 EEABC28C0D8 for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 10:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.497
X-Spam-Level:
X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[AWL=1.607, BAYES_05=-1.11]
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 7hgsq+34GqSn for <ietf@core3.amsl.com>; Thu, 1 Jul 2010 10:49:35 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 0980628C0D0 for <ietf@ietf.org>; Thu, 1 Jul 2010 10:49:35 -0700 (PDT)
Received: by pvd12 with SMTP id 12so1220755pvd.31 for <ietf@ietf.org>; Thu, 01 Jul 2010 10:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DEK4W7sH8FjMnZbILVxOP1mN2vnsdUB/ohXWN5byrcI=; b=PotNH4yECwm8Snmkc5tLhARJP61OI95WIEOT4PaNZEcznUDZVvwfmHR+yyGSBEazym wq9LFA7RNLkJ59fUs5/lpDNNj25Kd+0E71MYqJ5XQvxlS5IIL1XCdYQ81qIm3gyc/plX pACLndvM7cPvGHmGYE9V16IkluDfW39P6Mh/w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rI4Ze9lV4y7UuUy4n5i9ZPYZcGa8qBUFp7DHF8u/MlSGDj6I0A5TLizT2myuIBmHnv wSpNbTXBfdV5YvJ0BhOKdW2OpPN8zXrooHz619UYXv2RkDoeDgn0+LXGnS9MgCejWqdG F1KhzqltmA8/jT92hGWgLe1RGnkgM2eM7bJG4=
MIME-Version: 1.0
Received: by 10.142.247.37 with SMTP id u37mr11715859wfh.199.1278006578305; Thu, 01 Jul 2010 10:49:38 -0700 (PDT)
Received: by 10.143.39.20 with HTTP; Thu, 1 Jul 2010 10:49:37 -0700 (PDT)
In-Reply-To: <700E34E1-6B18-4D6E-B0C5-DC98174C45C9@bbn.com>
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>
Date: Thu, 01 Jul 2010 10:49:37 -0700
Message-ID: <AANLkTinDMVXzw04aJFnoxqrnV5BZ9XCa73Z0hzZ0J57k@mail.gmail.com>
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
From: Ted Hardie <ted.ietf@gmail.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dcrocker@bbiw.net, IETF <ietf@ietf.org>
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: Thu, 01 Jul 2010 17:49:36 -0000

On Thu, Jul 1, 2010 at 8:52 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> 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.

Just two cents,

Ted Hardie