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