Chris Hart wrote:
At Northwestern University we are looking to move away from using VPN
for Authentication and Encryption for our wireless users.
We do not want to have to use 3rd party supplicants because of end
user support issues.
We are currently using Funk Steel Belted Radius and have tested using
802.1X with PEAP on Windows and MAC so far in small numbers with success.
TTLS does not have a built in supplicant for Windows XP and TLS
requires a per client certificate so these are not good options.
This leaves PEAP or using an appliance of some sort to provide an
IPSEC tunnel or a Secure desktop SSL connection.
So my questions are
1. Am I missing other options?
There is a free plug-in to the native Windows XP supplicant that will
provide TTLS functionality. You might check our SecureW2.
(http://www.securew2.com) We have been using it here for a couple of
years, with minimal problems. The problems that we have had are usually
related to other pieces of software that conflict with parts of
Windows. (Such as the Norton firewall and it's conflicts with the
Windows XP SP2 firewall.)
2. Is PEAP a good solution - is it secure, client issues?
PEAP is an odd duck. I could probably go on and on for hours about PEAP
and all of it's good and bad points. But I'll stick to the question.
Is it secure? -- It depends largely on what you are concerned about
security-wise. PEAP is a two phase protocol. The first phase
establishes a TLS tunnel (very similar to the way that an SSL tunnel is
built with a web server). The second phase carries another EAP
conversation inside the tunnel. (Usually the inner conversation is EAP
MS-CHAPv2, but it doesn't have to be. That is just what Micro$oft
defaults to.) So, the data inside the tunnel is as secure as anything
else that uses TLS/SSL.
For the inner part of the authentication, you need to ask yourself if
you believe that MS-CHAPv2 is secure. But, more importantly, you need
to consider where and how your passwords are stored. In order for
MS-CHAPv2 to work successfully, you need to store your password in one
of three different formats. 1. MS-CHAPv1 format. 2. Reversably
encrypted. 3. Cleartext. There are tools out there that can crack an
MS-CHAPv1 format password in a fairly short period of time. And
obviously reversably encrypted passwords require that the decryption key
be available on the server. So, keep this in mind when picking an EAP
method. (This issue was enough for our campus security people to tell
us that we can't use PEAP.)
Another problem with both PEAP and TTLS is the compound binding
problem. Specifically, there is nothing that is done to verify that the
system that established the TLS tunnel is the same system that is doing
the inner authentication. So, a bad guy could put up a fake AP, and
wait for a user to connect. The fake AP could terminate the TLS
session, and create a TLS session with a valid AP at the same time.
Then, the inner phase could be bridged through to the real AP. The real
AP sends back a success, the fake AP sends a failure, and the bad guy is
on your network using someone elses credentials. Newer versions of
PEAP and TTLS attempt to address this problem, but are not generally
available yet. (But then, I am not aware of anyone that has seen this
type of attack in the wild either.)
So, I guess the "short" answer to your question is, like every other
security protocol out there, you need to decide if the benefits outweigh
the potential problems.
Are there client issues? -- This is where I could write a book about the
problems with PEAP. (Keeping in mind that in many environments these
may be non-issues.) There are currently three different versions of
PEAP. Version 1 is the "Cisco and Microsoft working together version".
This version of the internet draft is similar to what is implemented in
Windows XP, except that neither Cisco nor Microsoft follow it
completely. Version 0 is what is actually implemented in Windows XP.
The closest thing there ever was to a standard on this is a short
document that lists some (but not all) of the differences between
Version 0 & 1. Then, there is version 2. Version 2 is the attempt to
solve the compound binding problem. Currently I am aware of only 1
implementation in a supplicant, and none in a server.
So, if you are running Windows XP you probably won't have many client
issues, since pretty much every RADIUS server in the world supports
PEAPv0. On Mac OS X, there is a bug in Panther that would cause the
supplicant to get grumpy if it were presented with the start of a PEAPv1
conversation. You could resolve this by forcing the RADIUS server to
only speak PEAPv0. I am not sure if this was resolved in Tiger or not.
Another issue with PEAP that will probably dog some of the supplicant
implementations is how to correctly use DOMAIN\user. IIRC, you need to
use DOMAIN\user in the outer part of the 802.1X authentication, but you
need to use just "user" for the inner part or else authentication will
fail. (This inconsistancy bites a lot of people that aren't using
Windows, since most supplicants don't care what format your username is in.)
One last thing that probably isn't a big issue, but is probably good to
know. PEAP makes use of some reserved bits from the EAP-TLS standard.
These bits are used to determine the version number of PEAP that you are
using. But, there are only 2 bits available. So, if they don't get it
right by PEAPv3, they are done. ;)
Hope this helps!
thanks
Chris
Chris Hart
(847) 467-7747
IT-TNS
Northwestern University, Evanston
[EMAIL PROTECTED]
**********
Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
