Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I asked a question recently about setting up WPA2 enterprise, and I have a couple of ancillary questions. First, regarding the use of the OpenSSL cnf files for the certificate generation. I have a number of them in /etc/raddb/certs, which came in part of my freeradius installation on my Gentoo box. I have a ca.cnf; server.cnf and client.cnf. My questions are as below:

  1. If i want to set up username/password-prompt-less setup for WPA2 enterprise (I want the users file to use certificates)--can I do this following the same procedure I followed for "The windows XP client" in Step 1 of freeradius howto? I will add the eap.conf configuration as mentioned in the answer to my question above. Note that this is an issue I am facing in Mac OS X based systems. My windows XP/SP3 laptop does not seem to have this issue, as I added the ca.der file (double-click install), and the client.p12 file to it (see freeradius howto, under Step 1, "The windows XP client").
  2. How do I import the specific keys onto iPhones and other personal devices such as iPads, Android tablets etc.?
share|improve this question
    
This is not an answer to your question, but something to think about in such a setup: Why allow personal devices on a network? Did you give you full rights to encrypt the devices or delete all data on all of those devices if they ever got lost? If not then BYOD is a really bad idea from an admin/security point of view. –  Hennes Jul 24 '12 at 13:19
    
@Hennes: this is for a home network. However, the "personal" in the personal devices really means phones, ipads which typically support only one user (no username/account/password business on an iPhone). Note that you could have a corporate mobile device that needs to get onto WPA2 enterprise securely. Eg. corporate iPhones and iPads. I use such devices regularly in my line of work. –  Sonny Jul 24 '12 at 14:42
    
Aye. I know places which use them. E.g nurses with an ipad and a custom application. However I also know several corporate places where all desktops and laptop got tied down with full HDD encryption, but all data was allowed onto BYOD machines without any security. I guess that still itches. –  Hennes Jul 24 '12 at 14:47
    
I run full disk encryption on all my home computers. Doesn't everybody? –  Michael Hampton Jul 26 '12 at 1:34
    
@MichaelHampton: Heh heh ... :-) Comment appreciated. This is part work-based project, part paranoia, but I have family members whose WiFi has gotten hacked (resulting in bad things thereafter), and I know they appreciate it when I tell them I have military grade security on the home WiFi network. The part of about WiFi security is not about home security (inside the home, you can trust), but prevention of your (global) IP address being used by random strangers, not to mention hogging bandwidth. Now, none of this is security enough for a determined hacker. I'll give you that. –  Sonny Jul 26 '12 at 12:02
add comment

1 Answer 1

up vote 0 down vote accepted

After much poking around man pages for openssl.cnf and the configurations on the various iPhones and iPods at home, I have finally figured out the answer to the question I posed.

My solution achieves the following: (a) username/password-less logins in a secure manner using EAP-TLS via WPA2-enterprise, and (b) (maybe a teeny bit stronger security) password-less but username required login in a secure manner via WPA2-enterprise. The option (b) is really by uncommenting check_cert_cn in the eap.conf file, and requiring the username (there are a number of name attributes, be a little careful) is sent. A potential hacker could have your certificate, but she possibly does not have your username, but this is not exactly a security measure for a hacker who knows her way around certificates and WPA2 enterprise.

In a gist, the procedure is that you will change the client.cnf file for each client you want to add into the network and regenerate the keys using make client.pem, which produces the client.p12 file which you should download onto your client machines--this means each client gets its own key for the encryption, which implies one client in the network cannot spy on another's packets via promiscuous mode. If you have any issues during the creation of the client.pems: make client.pem bombs for any reason, then pay special attention to serial and serial.old, and index.txt and index.txt.old: specifically, mv serial.old serial and mv index.txt.old index.txt, and redo the make client.pem after the problem is fixed (e.g., incorrect cnf file due to typos--most likely due to the fact that special characters are sometimes not permitted for the passwords in the client.cnf file--I would appreciate anyone reading this to point me to resources regarding the use of special characters in *.cnf files).

Now the details: Windows machines need a different procedure: For each Windows XP client, you will need to use the techniques mentioned in the README file in /etc/raddb/certs/. Next, you should follow the steps in "Step 1: Create Certificates: On the Windows XP client" in the FreeRadius howto, and connect using Step 4 of the same howto in the FreeRadius site.

For all machines, before you do the above for each client, you should change the client.cnf file for usernames and passwords for each of the clients. My cnf files changed really only touched the [ req ] section of the client.cnf file to change distinguished_name, input_password and output_password. Note that the following section should describe the name of the client described as the value for the distinguished_name attribute. For example, if you had distinguished_name = beeblebrox in the [ req ] section, then the following section will start as [beeblebrox ]. Here, you will configure the attributes accordingly boringly (same for most clients in your network, except the emailAddress, which will change for each client).

At the end of this process, you are done generating the *.p12 digital profiles/personal information exchange file for each client. This file contains a private key which the client will use for communication in the network. Now you have to install these digital profiles on to the clients.

Windows machines will take the procedure for installation of the certificates and the connection to the WPA2 enterprise network as already mentioned above. All the other machines need the *.p12 file that was created for them (it is convenient to name them per client: xp1.p12, xp2.p12, ios1.p12, ios2.p12, macosx1.p12 etc.) to connect to the RADIUS server. How do you download the *.p12 file onto the machines securely? For laptops, the problem is trivially solved by the use of removable media or if you are connected via ethernet to the host network, an scp of the file. For iPhones and other devices, it is a tiny bit tricky. I am not sure if using insecure email is the way to go, considering the fact the *.p12 file contains the private key to be used by the clients. Perhaps you digitally encrypt your email so it is OK. But I solved it by hosting the *.p12 files locally on a webserver and downloading them onto the IOS devices.

On the MAC, you can follow the steps provided in here but make sure you add the *.p12 file to the keychain on your MAC before you do so (see here). The 802.1x authentication in your WPA2 enterprise configurations (you may have to explicitly check TLS in the configuration).

On the IOS devices, you first download the *.p12 file which will let you add this certificate as a profile (download of the *.p12 file starts the process automatically). Then, you go to settings->WiFi->add your WPA2 enterprise network, and specify the SSID, and then change the mode to EAP-TLS. Once you do that, the Identity option appears, which, when you click, offers the *.p12 profile option. Check the option, and return to the screen. Depending on whether or not you have chosen total username/password-less login to the enterprise system, or password-less login, you may have to enter the username from the corresponding client.cnf file used to generate the *.p12 file. Once you click join, you are in!

I'd appreciate someone adding the plug for wireless access via linux.

I'll pipe in once I can talk more on the number of times I have to re-login etc.--I might have seen this problem on my IOS devices, but I have to check again.

share|improve this answer
    
a client connected to a WPA2 protected wireless network can not sniff the non-broadcast packets of another user, even if there is a shared key. a per-client key is derived when the client associates to the AP. therefore, clients can not decrypt the packets of other clients. –  longneck Jul 26 '12 at 1:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.