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

[Chris Elliott <[e-mail]>]

Phillip,

I read all of all your emails on this thread before I replied the first time, just not your book.

We will be and we have been "eat[ing] the WiFi authentication dog-food" at IETF meetings. And it's gotten easier each time.

You do realize, don't you, that we are offering WPA/WPA2 with enterprise authentication and encryption as our recommended way of getting onto the network, right? We are only offering a web portal so that folks that can't do WPA* can authenticate. And we've been offering WPA* enterprise on most IETF networks for many years. The difference this time is we are going to unique user credentials.

I anticipate the time it will take for most attendees to authenticate will be the time it takes to type in a username and password--far under a half an hour, unless the attendee is Stephen Hawking, in which case I will personally help the attendee authenticate! There will be those with problems. That's why there's a help desk.

Chris.

P.S. bring a copy of your book to Maastricht and I'll bring a copy of mine and we'll do a prisoner exchange. :-)


--
Chris Elliott
CCIE # 2013


On Jul 12, 2010, at 2:35 PM, Phillip Hallam-Baker <[e-mail]> wrote:

> Well maybe if you read the full thread rather than just cherry picking
> parts of it you would have understood the point better.
> 
> My original argument was that I think the IETF should eat the WiFi
> authentication dog-food here because the current product tastes like
> poo and the only way things are going to get any better is if a bunch
> of network engineers start to see that there is a real problem.
> 
> 
> I have also proposed a scheme that would be applicable for use at the
> IETF. Basically the shortest distance from where we are to where we
> want to be is to use self signed certs and use the fingerprint of the
> cert as a unique device ID. But that is only addressing the specifics
> of how to make the scheme work at IETF, which is really not very
> interesting in the grand scheme of things. What is more interesting
> would be a scheme that can be relied on to work anywhere without half
> an hour of fiddling and jiggering the configuration - as will be the
> Maastricht/Beijing experience.
> 
> The first year they started doing this at RSA the help desk had a
> pretty long queue and much time was spend debugging crappy code. The
> basic experience being that Macs work fine, Windows works fine with
> native drivers. But corporate configuration laptops with device
> drivers written by the WiFi card provider and/or VPN products were
> massively flaky..
> 
> 
> On Mon, Jul 12, 2010 at 1:53 PM, Chris Elliott <[e-mail]> wrote:
>> On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker <[e-mail]>
>> wrote:
>>> 
>>> No, if you read my book you would see the scheme I am proposing.
>> 
>> 
>> I hope your book is rather less opaque than your attempts to explain your
>> technique here.
>>> 
>>> 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.
>> 
>> I thought we were talking about how to do this for the meeting in Maastricht
>> and then in Beijing. I agree that manufacturers could make this easier for
>> all of us. But some of us live in the real world and must make things work
>> today.
>> I'd be glad to listen to an explanation of how to make this work with the
>> current devices that IETF attendees will be bringing to Maastricht and
>> Beijing.
>> Chris.
>> 
>>> 
>>> 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 <[e-mail]>
>>> 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
>>>> [e-mail]
>>> 
>>> --
>>> Website: http://hallambaker.com/
>> 
>> 
>> 
>> --
>> Chris Elliott
>> [e-mail]
>> CCIE # 2013
> 
> 
> 
> -- 
> Website: http://hallambaker.com/