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