Wireless Access

by default WPA2 AES-CCMP is 128-bit non-configurable.

If we purchase an ACR license.

 

It is configurable?

This seems to point to that

http://www.arubanetworks.com/techdocs/ArubaOS_64x_WebHelp/Content/ArubaFrameStyles/VirtualAPs/SSID_Profiles.htm

 

wpa2-aes-gcm-128	WPA2 with AES GCM-128 (Suite-b) encryption and dynamic keys using 802.1X. NOTE: This parameter requires the ACR license. For further information on Suite-B encryption, see SSID Profiles.
wpa2-aes-gcm-256	WPA2 with AES GCM-256 (Suite-b) encryption and dynamic keys using 802.1X. NOTE: This parameter requires the ACR license. For further information on Suite-B encryption, see SSID Profiles.

The datasheet makes reference to VIA. Is this required?

Do we need VIA licenses and clients installed on all machines?

 

or can we simply add the ACR license and change the encruyption of our 802.1x EAP-TLS SSID.?

You will need VIA (or another supplicant that supports SuiteB/gcm-ciphers) as standard supplicants will not support that encryption.

 

Some more information is in the ArubaOS User Guide (6.5.0.0 page 434):

Suite-B Cryptography
The Suite-B (bSec) protocol is a pre-standard protocol that has been proposed to the IEEE 802.11 committee as an alternative to 802.11i. The main difference between bSec and standard 802.11i is that bSec implements Suite-B algorithms wherever possible. Notably, AES-CCM is replaced by AES-GCM, and the Key Derivation Function (KDF) of 802.11i is upgraded to support SHA-256 and SHA-384. In order to provide interoperability with standard Wi-Fi software drivers, bSec is implemented as a shim layer between standard 802.11 Wi-Fi and a Layer 3 protocol such as IP. A controller configured to advertise a bSec SSID will advertise an open network, however only bSec frames will be permitted on the network.

 

And the VIA UserGuide 3.x for Windows page 104,108:

Enable Supplicant If enabled, VIA starts in bSec mode using L2 suite-b cryptography. This option is disabled by default.

 

If you really need SuiteB in government deployments on WLAN level, it may be best to contact our Federal team.

 

It appears that the new WPA3 standard includes stronger ciphers as part of many other security improvements.

Thanks Herman for the detailed response but let me work backwards and explain the problem statement.

Auditor comes in and asks is your WPA2-AES SSID (corporate one) wpa2-aes-128 or wpa2-aes-256-bit.

According to the ArubaOS hardening guide it says 128-bit. Other people have mentioned by default as of AOS 6.3 it is 256-bit. I can't find such information in release notes..

If it is not 256-bit by default, then we would require an ACR license w/ VIA which I understand the reasons for it.

Pmonardo,

 

Are you asking about a wifi supplicant or a VPN supplicant?  WPA2-AES-CCMP is 128 bits as per the standard.  If you want stronger encryption, the ACR license and suite-b for wifi, all of your clients will require a new supplicant that supports those encryption types.  Very few organizations do this.

Hi Cjoseph,

Wi-Fi supplicant and what you said makes perfect sense. I just need confirmation that WPA2-AES-CCMP is 128 bits but threads like this throw me off so I am not sure what the answer is.

http://community.arubanetworks.com/t5/Security/What-is-the-bit-rate-for-AES-encryption-on-6-4-code/m-p/249745

According to: https://en.wikipedia.org/wiki/CCMP_(cryptography)

 

... CCMP (CCM mode Protocol) is an encryption protocol designed for Wireless LAN products that implements the standards of the IEEE 802.11i amendment to the original IEEE 802.11 standard...

 

... CCMP is based on AES processing and uses a 128-bit key and a 128-bit block size....

and if you want to move to 256-bit or 384-bit, AES-CCM is replaced by AES-GCM using the ACR license which enables Suite-B (bSec).

Got it.

I believe the confusion lies within WPA2-PSK, where the PSK can be 256-bits in length.

The standard, as mentioned previously is 128-bits for CCMP.

256-bit and 384-bit was added but requires an ACR license to enabled WPA2-AES-256 or 384.

If no one disagrees, thank you Herman and Colin very much.