wireless PEAP with EAP-MSCHAP v2 authentication - certificate spoof possible?

Greetings,

I have a Cisco/Microsoft Wireless security question that's pretty
in-depth. I'm hoping there's someone out there who's been down this
road. Specifically I'm curious how strong this setup is in deflecting
a targeted evil-twin man-in-the-middle access point attack against our
employees (i.e. bad guy in airport or starbucks setting up an access
point trying to get an employee machine to associate to it and get the
machine to volunteer the active directory username/password).

Our networking vendor is spec'ing a wireless system for a large
facility, and intends to use Cisco Aironet infrastructure, and
leveraging PEAP authentication against our Microsoft Active directory
suing username/passwords. All our client machines are Windows XP
systems.

Their technical guy showed in a demo that Windows would be configured
for WPA/TKIP using 802.1x authentication using PEAP, and EAP-MSCHAP v2
as the authentication mechanism which'll go against our active
directory infrastructure.

Client systems (for our wireless workstations) will be set up to
validate the access point's certificate which they intend to use an
[name of a listed certificate authority] authority certificate for
this. Perhaps this picture helps, where only one trusted root CA
would be checked in our configuration:
http://www.cisco.com/univercd/illus/1/29/103429.gif

The benefit they say is that we won't have to install any client side
certificates which will simplify management quite a bit but, here's
where the big question of security comes...

In this setup, would it be possible for an attacker to set up
an evil twin access point if they take the time to purchase
their own certificate from that same certificate authority?

My understanding may be flawed, but I don't see that the client checks
anything except that the access point has a matching BSSID and
posesses a valid certificate from that certificate authority. I don't
see where it does any checking to make sure that it's actually our
company's individual certificate.

Can anyone confirm or deny?

I guess I'd hate for someone with a laptop sitting at an airport being
able to coax one of our employees' machines into joining his network
automatically if he just knew out BSSID and had a certificate from the
same CA. It may be an acceptable level of risk to balance out the
management headache or client side certificates, but I just want to be
sure we know what the exposure is so we can do a proper risk
assessment.


Best Regards,
--
Todd H.
http://www.toddh.net/

Hi Todd,

When dealing with digital certificates it is all about established
trust.

There is a chain linked to all certificates that leads back to the main
certificate authority.

If you "trust" that authority as having done their job then you
assume they have verified the certificate owner because there are
digital certificate links that lead back to the top authority.

If you do not trust them then you can get a certificate from another
authority, perhaps even setup your own root authority that is 802.1x
compliant.

Actually, even Microsoft provides this type of solution.

With 802.1x you cannot only authenticate the access point, but you can
authenticate the end points and users as well.

In addition, the 802.1x leads into network access control (NAC)
solutions and this is the true direction mature organizations should be
heading.

Courtesy of CompuCom Systems Network Security Expert, Andrew R. Reese:

http://www.bradreese.com/andrew-r-reese.htm

------------------------------

Hope this helps.

Brad Reese
BradReese.Com - Cisco Repair
http://www.bradreese.com/cisco-big-iron-repair.htm
1293 Hendersonville Road, Suite 17
Asheville, North Carolina USA 28803
USA & Canada: 877-549-2680
International: 828-277-7272
Fax: 775-254-3558
AIM: R2MGrant
BradReese.Com - Cisco Power Supply Headquarters
http://www.bradreese.com/cisco-power...-inventory.htm

"www.BradReese.Com" <(E-Mail Removed)> writes:
> Hi Todd,
>
> When dealing with digital certificates it is all about established
> trust.
>
> There is a chain linked to all certificates that leads back to the main
> certificate authority.
>
> If you "trust" that authority as having done their job then you
> assume they have verified the certificate owner because there are
> digital certificate links that lead back to the top authority.
>
> If you do not trust them then you can get a certificate from another
> authority, perhaps even setup your own root authority that is 802.1x
> compliant.
>
> Actually, even Microsoft provides this type of solution.
>
> With 802.1x you cannot only authenticate the access point, but you can
> authenticate the end points and users as well.
>
> In addition, the 802.1x leads into network access control (NAC)
> solutions and this is the true direction mature organizations should be
> heading.

Hi Brad, thanks for your response. Let's assume we trust the
certificate authority in question to verify that someone is who they
say they are.

I guess my question boils down to this: Does PEAP (using only server
side certificates) really give a client any assurance that they're
connecting to their company's access point, or does it only guarantee
that they're connecting to an access point where the owner has
purchased a certificate from a given CA?

As a recap, we're talking about the sitation where the client is
configured like this, with exactly one of the Microsoft listed Trusted
Root CA's checked in this dialog box:
http://www.cisco.com/univercd/illus/1/29/103429.gif

I'm thinking a bad guy, knowing only what CA a Big Company uses, could
cheerfully purchase a certificate in his own name or his own company's
name, the CA would do their job and verify who he is and all, and then
head down to the airport with his laptop and see what laptops from Big
Company he could get to autojoin his access point because I suspect
that this method isn't checking the content of the certificate other
than for validity and for a trusted CA.

Or am I all wet?

--
Todd H.
http://www.toddh.net/

Hi Todd,

Recommend that you check out Verisign's FAQ section and review what
kinds of digital certificates are available for purchase, and then
review what the requirements are to get these digital certificates
assigned.

As stated earlier, it is about trusting the certificate authorities.

If you do not trust the root authorities to properly check the
credentials of someone before handing out a digital certificate in some
companies name, then setup your own root server and architect it from
there.

Am sure the root authorities post their policies and procedures for
ensuring the integrity of their root servers.

The client has the responsibility for accepting the validity of what
ever certificates are presented to them, they need to verify the chain
of trust back to the root server and they need to make sure the digital
certificate they have for the root server is valid.

Sincerely,

Brad Reese
BradReese.Com - Cisco Network Engineer Directory
http://www.bradreese.com/network-engineer-directory.htm

"www.BradReese.Com" <(E-Mail Removed)> writes:

> Hi Todd,
>
> Recommend that you check out Verisign's FAQ section and review what
> kinds of digital certificates are available for purchase, and then
> review what the requirements are to get these digital certificates
> assigned.
>
> As stated earlier, it is about trusting the certificate authorities.
>
> If you do not trust the root authorities to properly check the
> credentials of someone before handing out a digital certificate in some
> companies name, then setup your own root server and architect it from
> there.
>
> Am sure the root authorities post their policies and procedures for
> ensuring the integrity of their root servers.

That's true, but not applicable to the scenario I'm posing.

I'm trying to explore suppose a completely legitimate, non-forged
certificate is purchased in the attacker's name, and is associated the
the rogue access point. The real and rogue AP's will have different
certificates, but both certs are from teh same CA. Will PEAP
EAP/MSCHAP v2 as implemented in Windows XP sp2's built in PEAP
supplicant ever tell the user about the certitificate or not, or will
it quietly and happily connect to the rogue access point since it has
a cert from the trusted CA?

For the purposes of this, assume the "Connect to these servers" field of
this dialog is blank, and one CA of the trust list is selected to trust:
http://www.cisco.com/univercd/illus/1/29/103429.gif


> The client has the responsibility for accepting the validity of what
> ever certificates are presented to them, they need to verify the chain
> of trust back to the root server and they need to make sure the digital
> certificate they have for the root server is valid.

Right. I couldn't agree more.

But, my question is "Will the microsoft PEAP supplicant even ask the
user to okay the certificate that is presented, or will it quietly
accept it because it came from the trusted CA?"

Thanks again for your input!

Best Regards,
--
Todd H.
http://www.toddh.net/