Wireless Access

Has anyone had any success using MSCHAP v2 for  Aruba VIA authentication.. The current aruba tech I am working with says only PAP is supported until version 6.3 but that does not sound correct.  I have tried using my clearpass server for the auth, but it never even recieves the request it appears the client and server never aggree on proper Ike settings.

Currently it is giving the message:

IKE2_delSa: deleting IPSEC SA 166.137.215.173:31842 due to deletion of un-rekeyed IKE_SA

I have a server cert on the controller and pap does work... but i would rather not use it.

MSCHAP v2 is definitely supported; using IKEv2.    TheVIA Tech Note:  http://www.arubanetworks.com/wp-content/uploads/VIAAppNote_2012-06-11.pdf?repo=tech explains its support and usage.

So for the initial profile download, I am forced to use  clear-text PAP authentication?  The Aruba tech support staff just informed me that MSCHAPv2 for initial download of profile is not supported until v6.3.  It all sounded super insecure.  Something like:

Step1: Download Via Client

Step2: Send Password cleartext to auth for via profile download

Step3: Secure outer shell with Mschapv2 inner auth when you attempt to use the network.

All the security in the world for step 3 does not seem to matter if step 2 is sending the same credentials clear text.  Am I missing something, is there some additional security I don't see?

I will be the first to say that it's not as secure as it could be, but it's NOT the case that we're sending around cleartext passwords.  VIA uses an HTTPS session to initially authenticate to the controller and perform a profile download.  The password is sent inside that HTTPS transaction and is thus encrypted using TLS.

On the back end, the controller uses PAP to authenticate the user against a RADIUS server.  Even here, it is not cleartext over the wire - it is encrypted using the RADIUS shared secret.  RADIUS encryption is not really at the level of something like TLS or IPsec, and the security it does provide is directly proportional to the length and complexity of the shared secret, but a good shared secret does provide a reasonable level of protection - particularly since the network between the controller and RADIUS server is typically inside your datacenter, limiting the potential for someone to do packet captures on it (hopefully).  A number of people also set up IPsec tunnels between controllers and RADIUS servers as an extra measure of protection - this is common in the DoD for example.

Beginning in 6.2, you're able to authenticate captive portal users using MSCHAPv2 (previously only PAP was supported).  In 6.3, that same support extends to VIA web authentication (used for authentication to the WebUI for the VIA client download, and then used by VIA for the initial profile download).  MSCHAPv2 will also be available to authenticate VIA IKEv1 connections (through xAuth).  All of those use PAP today.

There are customers who simply refuse to enable PAP on their RADIUS servers for any reason, and although I think the danger is being overblown in this specific case, I understand why they have those policies.  My usual advice is to create a shared username/password in the controller's nternal user database for the purpose of profile download, and to then move to certificate-based authentication with IKEv2 for the actual VPN usage.  And of course once 6.3 comes out, we'll also have MSCHAPv2 support.

Hope that helps..