Security

Hi!

I see somewhat similar questions asked, but not quite so here goes.

Open SSID using https for authentication against Amigopd. Amigopod has a Radius Proxy for external authentication. This NPS Radius only allows MSCHAPv2.

I get reject when trying to authenticate directly from the Radius Auth test on Amigopod, and the NPS complains about wrong type. I'm able to authenticate if we open for PAP on NPS, but admins doesn't want to use PAP.

In the CP profile I added "Use Chap", but this didn't seem to do anything for the traffic between Amigopod and NPS since I still get reject.

Any other way I can force Amigopod to use MSCHAPv2 and not PAP?

.. John

Anyone got any information on this topic?

John

---

@jsolb wrote:

 

Anyone got any information on this topic?

 

John

---

Captive Portal only uses pap to authenticate.  That means from the client to the controller if you are using https:, the traffic is encrypted.  From the controller to the Radius Server, that is where it is not encrypted.  If you are really worried about traffic between your controller and radius server, you should try using wireless encryption.

Hi Colin,

Just to clarify.. I have https, and I'm using Amigopod with an external Radius authentication server (NPS and Windows AD). This external Radius server only accepts MSCHAPv2. There is no problem authenticating users registered on Amigopod - only towards the external Radius auth. server.. 

When using "AAA test server" I can choose MSCHAPv2 and I'm able to get "Authentication Succesful" using an account that is authenticated via Amigopod as proxy towards the external Radius auth server. Thats why I wondered if there was a setting to force this to be the authentication protocol for Captive Portal.

Is there an encrypted tunnel between Amigopod and Controller? Is the traffic between controller and amigopod not something the wireless clients are able to see? Or anything else that makes the use of PAP acceptable - cause as far as google can tell me PAP is seldom acceptable as an authentication protocol.

John

I think Aruba's sgtance is that traffic from the controller to radius server is on your (trusted) LAN where the client only has access to your (untrusted) guest-vlan. So on the untrusted client vlan you're using https to encrypt traffic where on the 'trusted' LAN it is in clear text PAP.

That LANs typically shouldn't be trusted is a whole other matter.

Could an Aruba engineer explain (in a bit of detail) why it isn't possible to use an encrypted mechanism from captive portal to radius server? I can't think of a reason why you should not enable security here if possible so why is it not possible?

My knowledge is limoted by the way, but don't the radius client and the radius server already setup a tunnel through which this PAP runs? Isn't that "outer" tunnel encrypting the "inner" PAP?

We are slowly getting our act together on this.  Starting in 6.1.3 you can enable MSCHAPv2 for management authentication.  Starting in 6.2 you can enable MSCHAPv2 for VIA authentication.  It looks like captive portal needs to be addressed as well.

There's nothing inherently difficult about this - we just need to do the work.

Note that passwords are NOT cleartext on the wire with PAP - they are encrypted using the RADIUS shared secret.  Assuming you chose a sufficiently strong RADIUS shared secret, it's not too bad.  Still, we understand RADIUS shared secret encryption isn't the greatest, and lots of IT departments don't allow PAP to be enabled on their RADIUS servers anymore, so we need to adapt.

I will get this into the release plan (will try to sneak it into 6.2) but for now there's not much we can do.  I will check with the Amigopod folks to see if it can "translate" in a RADIUS proxy situation.

Just as an FYI, bug 64436 (enhancement bug) has been filed to track the addition of MSCHAPv2 as an auth method for Captive Portal.

Thank you Jon! Awsome that you took the time to follow up on this issue.

And - yet another proof that Airheads rock!