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

[Phillip Hallam-Baker <[e-mail]>]

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/