Security

I'm sorry if this is a bit off topic but I'm not sure where else to turn...EAP/PEAP is a fairly complicated subject.

In PEAP the radius server (or the controller if the Aruba device is terminating the PEAP session) has a certificate. What's the best practice for how the client should verify the certificate? Should the user be left to accept the cert (as seems to be the case on MacOSX and iOS devices?) On a windows client w/a public CA, is it proper to specify Trusted root authorities via GPO? If you do that, wouldn't it be possible to export a cert issued by the trusted CA, import onto a rogue controller and collect PEAP session info?

If you have the certificate signed by a well-known public CA (Verisign, etc.), how does the CA verify the request? E.g., with a basic cert for SSL, the CA typically verifies that the request is acknowledged by an authorized contact for the domain. The CA can go further verify other business info as well to try to verify that someone from the actual organization approves. What does the CA do for a cert requested for PEAP?

Hi

If you have your own Public Key Infrastructure (PKI), you should try to get as many users as possible (certainly all windows domain PCs) to "validate server certificate". If anyone spoofs your server certificate, you can always revocate it.

If you have a well-known public CA, the CA public key is installed by default in your OS so no worries there. The downside of this is that you don't have any effective mechanism to revocate certificates, so what you gain in usability you lose in security.

BR

Does the client (the device, not the human) do any validation/evaluation of the cert signed by the public CA?

E.g., web browsers will compare the FQDN of website being visited with the common name on the certificate.  If they don't match, then even if the browser/OS trusts the CA, the browser will display an error.

I'm guessing the wireless client cannot do that--the cert might have a common name and subject alternate names, but there's no way for the client to "know" what device it is opening a session with, right?

Then I also wonder how to obtain a cert signed by a public CA.  What common name does one use?  Since most quick/cheap SSL certs are domain validated, does one just choose a FQDN that "sounds" official?  I assume the wireless client cannot verify this FQDN since it has not yet gained access to the network.

---

@golazo wrote:

Does the client (the device, not the human) do any validation/evaluation of the cert signed by the public CA?

>>>> Depends on the client

E.g., web browsers will compare the FQDN of website being visited with the common name on the certificate.  If they don't match, then even if the browser/OS trusts the CA, the browser will display an error.

>>>>Windows offers this option by using the "Validate Server Certificate" check box and supplying the common name of the certificate in the "Connect to these servers" and choose your trusted CA in the "Trusted Certificate Authorities" box.   If you have iOS you can use the iPhone Configuration Utility (despite it's name, it works on iPads) or some other provisioning tool to explicitly identify the Truest Server Certificate Names.  I am not sure of other

 

I'm guessing the wireless client cannot do that--the cert might have a common name and subject alternate names, but there's no way for the client to "know" what device it is opening a session with, right?

 

Then I also wonder how to obtain a cert signed by a public CA.  What common name does one use?  Since most quick/cheap SSL certs are domain validated, does one just choose a FQDN that "sounds" official?  I assume the wireless client cannot verify this FQDN since it has not yet gained access to the network.

>>>>If using a public CA, clients will typically use a CN that its user base can identify with; wireless.company.com or authentication.company.com.  Some may disagree with this approach, but it is what I have seen.

---

Thank you, that is helpful info.  Implementing PEAP properly is a bit confusing, esp. with so much depending on the client and the implementation on the OS. 

I've actually found implementing PEAP to be fairly easy.

Remember that with PEAP, the certificate is basically designed to protect your client - ensure they are connecting to your network and not a rogue or man in middle - your ability to protect who connects to your network is defined by your RADIUS implementation.

Many, many years ago we transistioned from LEAP to PEAP.  George Ou wrote an "ultimate" guide that helped tremendously.

For our Windows clients, we push the certificate and wireless settings out via AD and GPO.  When we were doing machine authentication, we were also adding Apple clients to the domain (not sure how we did that, but somebody figured it out).  Getting the settings to the Apple users was actually very easy - Apple makes it very easy to just trust the certificate.  We went a little further and required the machine authentication as well as put users into a specific AD group to gain wireless access.  

I know there is a lot of documentation out there, especially from Microsoft, and it looks very daunting.  Obviously I don't know what your specific requirements are, but I've found PEAP to be very straight forward.  You should still be able to find the guide from TechRepublic or ZDNet.