July 15, 2002
Update on PEAP and musings on Microsoft's 802.11 strategy
John Lettice over at
The Register has written a follow-up article
confirming Microsoft's security enhancements to its 802.11 offerings. Funny, I must have been out of coffee last night when I wrote my
original post on the subject, but after looking over
Microsoft's Cable Guy column again this morning, I saw 2 important points that I had missed.
First off, Microsoft confirmed in the article that the PEAP extension is in Windows XP Service Pack 1. So that moves the discussion out of the rumor category. Second, the folks at Microsoft explained how to set up PEAP and MS-CHAP V2 with an authentication server, simply using the AP as a pass through device.
That eliminates the need for a beefier AP, since the TLS sessions will get set up between the authentication server and the client. It also plays well into Microsoft's best interests, including its "digital hub" strategy, and its recent announcements about "Soft WiFi" where AP functionality will be built into a beefier computer that has an 802.11 radio installed. These strategies hinge on the house having at least one PC sitting on the wired net next to the cable
modem/DSL box, and that PC acts as the "digital hub" of the house. Now that box can function as the RADIUS and MS-CHAP-V2 server for secured 802.1x authentication as well.
This only fails to work if you've got one computer and a wireless combo
box with no home PC in the equation. Hmmm, potential trouble for the combo box manufacturers.
There are a number of issues surrounding the use of a PEAP scheme to
protect a home wireless network. First off is the issue of a valid TLS (aka SSL)
certificate on the AP; most home networks don't have an internal
Certification Authority, which menas that MS would have to preinstall a
certificate on each box they build, or offer a deal through one of the
known public CAs, like Verisign or Baltimore, etc. That costs the end user $$$.
Second is the issue of complexity - one of the biggest problems we had
even before we found out that WEP was broken was that about 80% of
people weren't even using WEP - they just plugged in the AP and didn't
change a single out-of-the-box setting. Of course, you can blame the
user in that instance, but I think tha opening up a new significant
vulnerability in a network is something that the vendor should not do,
even in the name of simplicity and user friendliness. You gotta work
harder than that to make a really compelling product - it should be
simple, user friendly, AND secure out-of-the-box.
Next comes the issue of legacy device interoperability. You know,
legacy devices like your new Mac TiBook, your Linux box, or that handspring Treo. The
problems with implementing a new handshake protocol into the network
connection phase is that all of the devices that haven't been built with
that capability obviously can't get on to the network. I'm sure that if
MS stays true to form, they'll put out a release of the Pocket PC OS
that will have PEAP capabilities.
Of course, you've still got the
whole trusted certificate issue to deal with, so if I was Microsoft, I'd
start selling inexpensive renewable certificates for these mini-IAS
servers. The other option for a home user is to self-sign their
certificate, and then go through a manual process of accepting the
certificate on each client that will be part of the network. This opens
you up to some man-in-the-middle attacks, especially for people who are
connecting for the first time, but it is certainly a level of protection
higher than what is out there today. The big problem remains is the
geekiness factor - you have to be a geek to use this stuff, sign your
own certificates, walk new users through accepting the certificates, and
so on, which menas that for most home users, this will remain a feature
that they leave turned off, fitting squarely into the "silly bunch of
checkboxes on that security tab that I just leave unchecked".
Of course, that fits nicely into MS' strategy as well - in order to
really secure your home network, you need to have a desktop PC plugged
into the wall - after all, it is holding all of the music and movies you
downloaded off of that cable modem, right? :-)
And your Mac or Linux box won't work, at least not until they
have PEAP clients that authenticate against MS-CHAP-V2, and do they have patents on that protocol? Gotta go ask someone on the Samba team...
Sorry, I really have to watch my evil empire bashing. :-)
All in all, considering the market power that Microsoft wields, this is pretty good news - PEAP is an IETF draft standard, and the world does need big players to help push standard strong authentication and security over wireless networks. And of course, that means more people will need good tools to manage those networks.
Posted by dsifry at July 15, 2002 7:06 AM
| View blog reactions
David,
Good column - I found it quite interesting.
I think the certificate issue is huge. The average consumer will have no desire to deal with certification. Actually - in some respects I'm really surprised that EAP-TLS and now PEAP, has gained traction. In my opinion, certificate management is an enough of an issue that I personally wouldn't let in the door.
However, since PEAP is a Microsoft initiative, it will probably be a market force.
I am a fan of EAP-TTLS - its very secure and does not require a certificate - although it does require client software. But at least client software does not have the same infrastructure management issues as certificates.
Of course both PEAP and EAP-TTLS require RADIUS servers. Can we really imagine the average home user setting up a RADIUS server?
I guess this all goes to show that good security is not simple.
Steph
A very good take on the situation. Like Stephanie, I'm a fan of EAP-TTLS (EAP-TLS if you don't have to worry about folks w/o certs as a corporate PKI infrastructure might have).
What's to stop someone like Linksys or D-Link from adding a mini-RADIUS server/MS-CHAP-V2 combo to their product? (RAM is cheap, embedded processors are beefy enough for a home network implementation). I'm not suggesting this is a good thing (actually, I'm suggesting the exact opposite).
I really wish EAP-TTLS had been given more of a go-round and a chance to live in the wild before the 800-lb gorilla made its move. However, the market forces go way beyond Microsoft for EAP-PEAP. If you take a look at the protocol very closely, you see that it really does work well in - say - a 802.11b "cell tower" type implementation where you seamlessly roam from AP to AP without much overhead on anything. I know this type of roaming it's possible with EAP-TTLS too (and more secure), but it has much more overhead.
The security problems with PEAP (re-read the RFC) still scare me...
A very good take on the situation. Like Stephanie, I'm a fan of EAP-TTLS (EAP-TLS if you don't have to worry about folks w/o certs as a corporate PKI infrastructure might have).
What's to stop someone like Linksys or D-Link from adding a mini-RADIUS server/MS-CHAP-V2 combo to their product? (RAM is cheap, embedded processors are beefy enough for a home network implementation). I'm not suggesting this is a good thing (actually, I'm suggesting the exact opposite).
I really wish EAP-TTLS had been given more of a go-round and a chance to live in the wild before the 800-lb gorilla made its move. However, the market forces go way beyond Microsoft for EAP-PEAP. If you take a look at the protocol very closely, you see that it really does work well in - say - a 802.11b "cell tower" type implementation where you seamlessly roam from AP to AP without much overhead on anything. I know this type of roaming it's possible with EAP-TTLS too (and more secure), but it has much more overhead.
The security problems with PEAP (re-read the RFC) still scare me...
Couple of things I've heard from Microsoft types:
PEAP and 802.11X support will be back ported to the current PocketPC edition. This is mostly so they can use their PocketPC devices around the Microsoft campus! Full support though will need the new new version of PocketPC.
You should be able to do a BSD implimentation of the PEAP stuff. They've published (or are about to) all the specs, but with the usual "no GPL" clause. I guess you'll need to put all the protected stuff in a BSD licencsed program, then call it (as a seperate program, not a license) from your GPL code. Such fun....
hi Steph et al.
First, talking about certificates, EAP-TTLS and PEAP are equal, i.e. neither of the both needs a deployment of client computer certificates. The main text here is correct stating the need for the accept of new server certificates only. Once more: in PEAP no client certificates are needed, just like in TTLS.
Now for RADIUS: being strict, neither TTLS nor PEAP dictate the use of RADIUS. In fact, when you read the drafts, you will find that RADIUS is not even mentioned. It's logical, since RADIUS is the protocol used between the Authentication Server and the NAS and the drafts describe a protocol between the supplicant and the Auth Server. If you want to be even more precise, according to the IEEE 802.1X standard the Authenticator and the Auth Server could be co-located. Their separation is explicitely declared optional.
Practically, however, you are right, but simply because today there is still no alternative to RADIUS. Such an alternative could be DIAMETER or COPS, not meaning that it would become easier to install/manage. Nevertheless, in the future such a "backend server" could be included in whichever wireless box (remaining 802.1X-compliant!), thus making the use of a real backend server unnecessary. I hope, this answers some of your doubts.
The much more interesting problem in my eyes is the question, why MS/Cisco/RSA submit the PEAP draft whereis the TTLS draft has been a draft for a while now. PEAP basically does exactly the same,
we could even say "copies TTLS"... More: in the PEAP draft, there is no word (neither critics nor deficiency nor existence) on TTLS. Now that's really weird.
Greetings,
artur
I've been working in GL integration in the OMG AR/AP project, in ebXML, and in XBRL. There is an uncanny similarity between the GLs in the infrastruc. layers such as DIAMETER and at higher layers of the stack. Individuals need an end-to-end principle between their root ledger and anybody else before they can conduct bus. since nobody ever, in history has ever ever delegated their GL or custody of thei wallet to anybody.
Help us people,
Todd Boyle CPA
editor www.arapxml.net
http://www.gldialtone.com/IETFaccounting.htm
http://www.gldialtone.com/devices.htm
I'm founder and CEO of Technorati. I was the cofounder and CTO of Sputnik and Linuxcare, founding board member of Linux International, and board member of AOTC. I've been around the block a few
times. Some might call me a serial entrepreneur. A more personal but less-updated site has more information about me - pictures, speeches, software, etc. You can contact me at david-blog@sifry.com.
