Security

Hi,

My scenario is "simple" - atleast in terms of the advertised BYOD.

Give users with iPads the option to go through the MDPS procedure with Amigopod. 

There will then be a second encrypted SSID using EAP/TLS the guests connect to afterwards.

We've followed the beta MDAC guide from may 2011, but it's not working. When connecting the iPads just keep prompting for "Password" and no input works - neither the correct password nor the username (which I saw mentioned somewhere should be enough). The installation of certs on the iPad looks correct according to the guide, as well as the certs I've installed on both the Amigopod and Controller. Amigopod is working as Root CA.

I opened a TAC case on the issue a few days ago, but with no response so I'm trying the trusted community before I start nagging. I notice from various posts I'm not alone on working our way to a MDPS installation. There are several that have similar question and either no solution or they are routed to TAC, and no explanation solves the post..

Would it not be possible to get an updated document explaining the updated procedures for MDPS? I've seen hints about it for a couple months here now (cam?). There are alot of various posts regarding MDPS issues as far as I can tell, but none of them gives a solution to the whole procedure - including certificates for the Amigopod web server which have many posts here.

I also see a post from cjoseph explaining something in the way of not needing to upload certs on the controller when using Radius which I'm thinking have something to do with a new way to implement MDPS also?

cjoseph wrote:

My statement above was only made in response to a specific question about setting up  a controller with a radius server using TLS.  It was not made with MPDS in mind and it should not be taken that way.

There are quite a few more things that the MDPS solution provides such as certificate distribution without IT Intervention, Certificate Revocation checking, integration of asset information and user information into the certificate, etc that is beyond a vanilla TLS deployment.

Thanks cjoseph, that clears that up.

Still I'm unable to get this darn thing to work, and the changes in the Amigopod GUI for this tells me there atleast have been changes to the procedure.

Unable to get pass the issue where iPad asks for Password when connecting to the SSID.

I've followed the guide to the letter. I can't trace the client traffic since it's basically not showing up on either controller or amigopod when connecting to the TLS ssid.

Let me try to give you some pointers on what could be causing the issue. If I understand your description correctly, you have successfully provisioned one of your test iPads and when you attempt to connect the TLS SSID you are getting prompted for a single password.

This is typical of a couple of scenarios that might be worth checking:

• time synchronization between the Amigopod signing the client certificates and the EAP termination point. I am assuming at this point you have the EAP-TLS terminated on the Aruba controller
• OCSP revocation check has failed. Again with EAP-TLS termination on the controller it is worth confirming that the OCSP revocation checkpoint is configured correctly and pointing to the correct OCSP responder URL on Amigopod. This is an example of the default URL published on Amigopod.

http://<Amigopod IP Address>/mdps_ocsp.php/1

Just to clarify the previous point about installed server certificates on the controller. This is only required when you wish to terminate the EAP-TLS on the Aruba controller itself. If you are intending on terminating the EAP-TLS on an external RADIUS then there will be no need to import and manage the certificates on the controller. The server certificate would be installed on the RADIUS server instead in this case.

In the more recent versions of Amigopod you can certainly opt to terminate the EAP-TLS transactions of your MDPS deployment locally on the internal RADIUS server. There is some discussion around this support and other changes to MDPS in the last couple of release notes associated with the 3.5 and 3.7 releases of Amigopod.

Hope this helps and I would be happy to follow up on your TAC case if you can 'pm' the case id.

Rgds

Cam.

Hi Cam,

thanks for the followup!

Case # 1277830 - since no pm is available here ;)

Yes - I've set the TLS-Termination to happen on the Controller, as per the guide.

The time sync is OK.

I've set OCSP in Provisioning Profile to the same as you pasted - with the correct IP.

I have installed a trusted SSL certiticate on the Amigopod server for the intent of using it for https on the guest portal self-registration, and just using Amigopod as Root CA for this MDPS part. 

John

In regards of the OCSP - I see that there is an option on the Controller to make it a OCSP client. I haven't done anything with that for this installation. Correct?

John

John,

I am not sure I follow your comment below.

'I've set OCSP in Provisioning Profile to the same as you pasted - with the correct IP.'

The only place OCSP would need to be configured in your deployment would be on the controller (or generally on the EAP Termination point).

I am sure the TAC would have requested this already but one of the more interesting debugs to run on the controller would be a show auth trace-buf whilst the iPad is trying to connect via TLS.

Rgds

Cam

Still no response from TAC on the supportcase from thursday. Been doing auth trace-buf without that seeming to tell me anything. This should be in the debug logs I've sent tho.

OCSP..

Well - the provisioning profile in MDPS on Amigopod has an option to add an OCSP url to the client certificate. I started without, then tried with it on - to the URL that is similar to the one you posted.

For setup of OCSP on the Controller.. I see this described on page 325-327 in the 6.1UG. What I don't see is how I'm supposed to create the OCSP responder certificate on Amigopod - as this is the Root CA. Any hints? :) I do have a certificate called the same as the root cert only added (signing) - might this be it?

John

From the auth trace-buf

Feb 6 20:55:39 station-up * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68 - - wpa2 aes
Feb 6 20:55:39 station-term-start * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68 95 -
Feb 6 20:55:39 station-term-end * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68/akme_TLS 7608 - failure
Feb 6 20:55:43 station-up * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68 - - wpa2 aes
Feb 6 20:55:43 station-term-start * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68 95 -
Feb 6 20:55:44 station-term-end * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68/akme_TLS 7608 - failure
Feb 6 20:55:45 station-up * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68 - - wpa2 aes
Feb 6 20:55:45 station-term-start * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68 95 -
Feb 6 20:55:46 station-term-end * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68/akme_TLS 7608 - failure
Feb 6 20:55:58 station-up * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68 - - wpa2 aes
Feb 6 20:55:58 station-term-start * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68 95 -
Feb 6 20:55:59 station-term-end * 34:51:c9:ab:a8:06 d8:c7:c8:25:a7:68/akme_TLS 7608 - failure

John

Hi John,

That is interesting looking at your trace. It appears that the client is never attempting to exchange it client certificate. If you have a look at this successful auth-tracebuf below you will see what is expected next in the transaction.

(Aruba6xx) #(Aruba6xx) #show auth-tracebuf count 20

Auth Trace Buffer

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

Jun 21 16:50:19  station-up             *  e8:06:88:9c:a3:50  00:24:6c:34:bd:8a                      -    -    open system

Jun 21 16:50:19  station-data-ready     *  e8:06:88:9c:a3:50  00:00:00:00:00:00                      1    -    

Jun 21 16:51:16  station-up             *  e8:06:88:9c:a3:50  00:24:6c:34:bd:8a                      -    -    open system

Jun 21 16:51:16  station-data-ready     *  e8:06:88:9c:a3:50  00:00:00:00:00:00                      1    -    

Jun 21 16:51:40  station-down           *  5c:59:48:aa:59:e8  00:24:6c:34:bd:80                      -    -    

Jun 21 16:51:45  station-up             *  5c:59:48:aa:59:e8  00:24:6c:34:bd:80                      -    -    wpa2 aes

Jun 21 16:51:45  station-term-start     *  5c:59:48:aa:59:e8  00:24:6c:34:bd:80                      1    -    

Jun 21 16:51:46  client-cert           ->  5c:59:48:aa:59:e8  00:24:6c:34:bd:80/corp-employee-dot1x  915  915  

Jun 21 16:51:46  client-finish         ->  5c:59:48:aa:59:e8  00:24:6c:34:bd:80/corp-employee-dot1x  -    -    

Jun 21 16:51:46  server-finish         <-  5c:59:48:aa:59:e8  00:24:6c:34:bd:80/corp-employee-dot1x  -    -    

Jun 21 16:51:46  server-finish-ack     ->  5c:59:48:aa:59:e8  00:24:6c:34:bd:80/corp-employee-dot1x  -    -    

Jun 21 16:51:46  eap-success           <-  5c:59:48:aa:59:e8  00:24:6c:34:bd:80/corp-employee-dot1x  -    -    

Jun 21 16:51:46  station-data-ready     *  5c:59:48:aa:59:e8  00:00:00:00:00:00                      1    -    

Jun 21 16:51:46  wpa2-key1             <-  5c:59:48:aa:59:e8  00:24:6c:34:bd:80                      -    117  

Jun 21 16:51:47  wpa2-key1             <-  5c:59:48:aa:59:e8  00:24:6c:34:bd:80                      -    117  

Jun 21 16:51:47  wpa2-key2             ->  5c:59:48:aa:59:e8  00:24:6c:34:bd:80                      -    117  

Jun 21 16:51:47  wpa2-key3             <-  5c:59:48:aa:59:e8  00:24:6c:34:bd:80                      -    151  

Jun 21 16:51:47  wpa2-key4             ->  5c:59:48:aa:59:e8  00:24:6c:34:bd:80                      -    95   

Jun 21 16:52:22  station-up             *  e8:06:88:9c:a3:50  00:24:6c:34:bd:8a                      -    -    open system

Jun 21 16:52:22  station-data-ready     *  e8:06:88:9c:a3:50  00:00:00:00:00:00                      1    -    

(Aruba6xx) #

This can sometimes indicate that the client is not happy with the client certificate for some reason and therfore wont initiate the certificate exchange. I will follow up on the support case and see what else I can find out.

Rgds

Cam.

I think the solution was to reset MDPS to factory defaults.

Hi Cam - and any other Airhead following this thread :)

I'm a happy man today because I finally got it working! What really caused the issue I'm not sure of, but as Cam says here I'm also thinking something was wrong with the certificates in one of the endpoints...

I got my hands on a somewhat updated version of the document - v1 dated June 2011 - which triggered a few new ideas and concrete explanation of the procedures involved. In short - correct certificates and OCSP

The longer story of what finally made it all work:

1. Factory reset MDPS with complete delete of certificates and settings

2. Reboot (just cause I'm not paranoid...)

3. Delete all profiles on iPad, reset networking settings, restart it..

4. Set up Amigopod as Root CA and create new root cert with new private key.

5. Export the certificated tagged with ... Certificate Authority (signing) as CA-signing.pem

• This is the suspected culprit from last round. Document describes only one type of certificate to export, and that is not the one tagged (signing). I did at one point try to export and install this on on the Controller, but I'm thinking things was just too messed up by then.

6. Create CSR on Controller 1024-bit

• I did use 2048 last time since 6.1.2.7 support this, but didn't want to take any risks now.

7. Upload CSR by copy/paste and export certificate as CA-EAP-Termination.pem

8. Install certificates on Controller

• CA-signing.pem as Trusted CA
• CA-EAP-Termination.pem as Server Cert
• CA-signing.pem as OCSP Responder Cert

9. Set up OCSP Responder using the installed OCSP Responder Cert

10. Then just follow the guide on creating the 802.1x profile, and WiFi+Provision profile in MDPS

Questions and/or things to try out

• in the Provisioning Profile I did not add a OCSP URL. Might cause some browser to fail - so what is best practice?
• http vs https on OCSP url.. What is best practice and why?
• Are there any extra security risks involved for the users if we allow guest user access to do this certificate enrollment and subsequently access ti the EAP-TLS network?
• EAP-Termination cert only lasts for 1 year, and it's no way to adjust this in the MDPS gui. Would definately be nice to be able to adjust this to last longer - just as the root cert. I'm guessing it might be possible to do it using openssl
• I see that a self-registered user with an account lasting 8 hours will get a certificate that lasts just as long - which is as expected. Will have to check and document the user experience when trying to reconnect after expired cert, and then try to re-enroll again using the open SSID.

So Cam - when will an updated document with description for enrollment of non-IOS devices come? :)

John - one happy airhead!

John,

Great news that you are all up and running now and a happy airhead.

Let me try to answer some of your questions inline below:

-----

 

Questions and/or things to try out

• in the Provisioning Profile I did not add a OCSP URL. Might cause some browser to fail - so what is best practice?

This option was added for compatibility with Microsoft NPS when EAP-TLS is terminated on this RADIUS server. This is not required for termination on the controller.

• http vs https on OCSP url.. What is best practice and why?

 

This would depend on your server deployment in terms of location between the controller and the Amigopod and whethet you are concerned about OCSP been seen in the clear. Typically this will be on a management network of some sort and may not be major risk. If you have a look at the OCSP spec you can see it is that it is transaction query based on the certificate serial number and depending on your security policy you may or may not want this encrypted in your environment.

• Are there any extra security risks involved for the users if we allow guest user access to do this certificate enrollment and subsequently access ti the EAP-TLS network?

The certificate enrolment kind of assumes the BYOD use case and that the user already has a valid account in a user store somewhere. There would be nothing to prevent you creating guest accounts in the local Amigopod database and then using these for cert enrollment but not sure if this is what you are after. You could then use the Check cert CN option under the 802.1x authentication profile to trigger a subsequent query to Amigopod and a role could be returned to the controller to provide differentiated guest access on the same TLS SSID.

 

• EAP-Termination cert only lasts for 1 year, and it's no way to adjust this in the MDPS gui. Would definately be nice to be able to adjust this to last longer - just as the root cert. I'm guessing it might be possible to do it using openssl

I would have to check on that - I know you can adjust the certificate validity time in the Provisioning Settings but I think this is just for client certificates. Not sure on the server certitifcate side of things.

 

• I see that a self-registered user with an account lasting 8 hours will get a certificate that lasts just as long - which is as expected. Will have to check and document the user experience when trying to reconnect after expired cert, and then try to re-enroll again using the open SSID.

Yes the MDPS will attempt to match the certificate validity time to that of the underlying account if available. TLS authentication will fail with an expired client cert and re-enrollment will be required.

 

 

So Cam - when will an updated document with description for enrollment of non-IOS devices come? :)

 

John - one happy airhead!

---

Thank you for the clarifications Cam! Now on to the next challenge :)