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 <hallam@xxxxxxxxx> 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 <chelliot@xxxxxxxxx> wrote: >> On Mon, Jul 12, 2010 at 12:07 PM, Phillip Hallam-Baker <hallam@xxxxxxxxx> >> 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 <chelliot@xxxxxxxxx> >>> 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@xxxxxxxxx >>> >>> -- >>> Website: http://hallambaker.com/ >> >> >> >> -- >> Chris Elliott >> chelliot@xxxxxxxxx >> CCIE # 2013 > > > > -- > Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf