It is good to know that what we are seeing is normal behavior and there isn't 
something mis-configured on our end, but some sort of documentation from 
wireless manufactures detailing this requirement would be helpful to show users 
what they are experiencing is just a security requirement and completely normal.

Thanks everyone.

Mike


Michael M. Williams
Network Systems Analyst
Information Technology Services
Tarleton State University
201st St. Felix Str.
Box T-0220
Stephenville, TX 76402
Tel: (254) 968-1850
Fax: (254) 968-9393
[email protected]<mailto:[email protected]>

Information Technology Services staff will never ask for your password in an 
email.  Don't ever email your password to anyone or share confidential 
information in emails.

Confidentiality Notice:  This electronic message, including any attachments, is 
for the sole use of the intended recipients(s) and may contain confidential and 
privileged information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:[email protected]] On Behalf Of Steve Bohrer
Sent: Monday, April 15, 2013 11:02 AM
To: [email protected]
Subject: Re: [WIRELESS-LAN] Verifying or Validating Server Certificate when 
using WPA/WPA2 and 8021x WLAN

On Apr 15, 2013, at 11:34 AM, "Williams, Mr. Michael" 
<[email protected]<mailto:[email protected]>> wrote:


  One of our wireless networks is configured to use WPA/WPA2 with 802.1x and 
PEAP w/ MSCHAP v2.  After updating the server certificate on the ACS, our 
wireless users were asked to verify or validate the server certificate before 
gaining access to the wireless network.

[...]

I know we are not the only one seeing this requirements, numerous other 
University have publish wireless tutorials asking their user to verify the 
certificate as part of the initial setup of the wireless profile.

[...]


Has anyone found a solution to this problem?  Or is this just the default 
behavior of the supplicant that we are seeing?



I believe this is by design, not a bug, as there is no automatic way for the 
client to associate the server's certificate with a particular 802.1x SSID. 
Only the user can do that, so it means your users need to know what server they 
should authenticate to. (Conversely, when you go to an https website at a 
particular domain, the browser can check that the certificate matches the 
domain.)

On campus, we use eduroam, and our users need to accept the certificate for our 
server when they first connect. We try to teach them that they should not ever 
need to accept another certificate until we update ours, which we will let them 
know about ahead of time via email.

So, after the initial setup here, if they ever try to join an eduroam AP, and 
get prompted about the server's certificate, they should cancel the connection 
so their device doesn't send their credentials to bogus server. This is the 
only defense against, say, a student setting up their own RADIUS box with an AP 
to broadcast as eduroam and then harvesting usernames and passwords.

Unchecking the "validate certificate" option on Windows removes your user's 
only defense agains such situations. Unfortunately, from what I've found, 
Android devices doing PEAP/MSCHAPv2 do not prompt for certificate, so with 
them, you don't get a chance to verify the server.

Steve Bohrer
Network Admin, ITS
Bard College at Simon's Rock
413-528-7645

********** 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/.

Reply via email to