IETF Logo Mail Archive

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

Phillip Hallam-Baker <hallam@gmail.com> Mon, 12 July 2010 16:07 UTC

Return-Path: <hallam@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 E71FE3A6897 for <ietf@core3.amsl.com>; Mon, 12 Jul 2010 09:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 fcu8gaYabtvn for <ietf@core3.amsl.com>; Mon, 12 Jul 2010 09:07:17 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8BB693A69A6 for <ietf@ietf.org>; Mon, 12 Jul 2010 09:07:17 -0700 (PDT)
Received: by gwj19 with SMTP id 19so391049gwj.31 for <ietf@ietf.org>; Mon, 12 Jul 2010 09:07:21 -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; bh=woi+NLvEyUrucEkV6JMF83jxL006nlJfY6PnQ0Q3ttM=; b=TQyeP6KXNFGYCsNpxNgMdLVWyNUcDVAjUs4SdNE0VVTWKnz4gBPv2Y+hOtIz2icqiv HumXR5jIOKLcII6kraeU0yHVKTpbcniuBlAzPUxKQQbica6E16ErIG3zzC7lzuNSgzvb RMQugVFexw306tHtAt+4ceGyZNZxzF/2hWElU=
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; b=ie+5SMTk8NAVGrJGZ2Yo3ZB1MRSJXfpaIFaGyCqCPz0+s8lTkEnq/ju29k710eS7uB aYmRW7PDl9h5GUNfkUPUz6h4rMB0F+/MpMtmnCjMDES+MMvr/5IYXn2yxLA7kh47WYHc +/n7ylYVUBZtqI6vuz0y3UTD1LlOsSlQTZQFQ=
MIME-Version: 1.0
Received: by 10.90.98.10 with SMTP id v10mr6199845agb.151.1278950827698; Mon, 12 Jul 2010 09:07:07 -0700 (PDT)
Received: by 10.231.32.8 with HTTP; Mon, 12 Jul 2010 09:07:05 -0700 (PDT)
In-Reply-To: <AANLkTil0YIS9H-vYxIJJS_OC7tAlcCLQQycskFcLE71V@mail.gmail.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> <AANLkTinMFsrGyIy9bu5kzUiZqNmDbf7lpS-eht8h3hvP@mail.gmail.com> <CCD1D0AD-97DC-4CE0-9E27-CC75B5F47C54@muada.com> <AANLkTilVmeg2Tgjgllg2yT3Oc34Y4ZuwXwl9U1ELfjhc@mail.gmail.com> <20100706170631.GK25518@thunk.org> <AANLkTil357pxy8tD49Q9ds9QVlSjo9h3p3akSN9UF1XS@mail.gmail.com> <AANLkTil0YIS9H-vYxIJJS_OC7tAlcCLQQycskFcLE71V@mail.gmail.com>
Date: Mon, 12 Jul 2010 12:07:05 -0400
Message-ID: <AANLkTilVAn3j-iXbdytu9en-OWAjlCFQSyQy1jiY1Zq1@mail.gmail.com>
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
From: Phillip Hallam-Baker <hallam@gmail.com>
To: chelliot@pobox.com
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailman-Approved-At: Tue, 13 Jul 2010 08:33:23 -0700
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, tytso@mit.edu, IETF Discussion <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: Mon, 12 Jul 2010 16:07:19 -0000

No, if you read my book you would see the scheme I am proposing.

The problem with current MAC addresses is that they are not
trustworthy. That is accepted. If MAC addresses were not trivially
forged then the existing WiFi scheme would work fine.

What I am saying is that if people got really serious about usability
and in particular the WiFi design had been controlled by a Steve Jobs
style person who demanded an absolute commitment to a first class
usability approach, then we could have a scheme that did not require
end-user configuration.

Instead every device would have been issued with a device cert to bind
the MAC address to a public key during manufacture. This is already a
requirement for cable modems. The cost is of the order of cents per
device if the certs are installed during manufacture. Maintenance
costs get much higher as soon as the device has left the factory.

The function of the certificate is to stop the MAC address being
trivially forged. OK yes, if you design the protocols wrong then you
can end up with Cisco being able to intercept on the wire traffic. But
if you do the job right you can prevent interception even if the
manufacturer defects.


And as for my waist - yes there does seem to be rather more of it than
there should be, but I don't think that is Dogbert's fault. I blame
the cookies at IETF break time.


On Mon, Jul 12, 2010 at 11:56 AM, Chris Elliott <chelliot@pobox.com> wrote:
> Phillip,
> In your earlier email, you state:
>>
>> If the designers had actual brains instead of bits of liver strapped
>> round their waist by dogbert then all that would be necessary to
>> securely authenticate to the network is to give either the MAC address
>> of the computer or the fingerprint of the cert.
>
> Note that you say "either". Now you state:
>>
>> Of course the MAC address is trivially forged. That is the function of
>> the certificate.
>
> Maybe you should check your waist.
> Chris.
>
> --
> Chris Elliott
> chelliot@pobox.com
>
>



-- 
Website: http://hallambaker.com/

v2.23.0 | Report a Bug | By Email