This is a request for comments to clarify network security proper usage of new AES-GCM cryptography functionality on the Cisco ASA platform. Please leave a comment if you can provide some insight to help readers better informed on how and when to use AES-GCM with the Cisco ASA. I’m using the documentation for reference: “CLI Book 3: Cisco ASA Series VPN CLI Configuration Guide, 9.7 – Chapter: IPsec and ISAKMP.” Quotes that I’m trying to decipher from the document follow:
- “When AES-GCM is specified as the encryption algorithm, an administrator can choose null as the IKEv2 integrity algorithm” – under section “IKE Policy Keywords and Values”
- “You must choose the null integriy algorithm if AES-GCM/GMAC is configured as the encryption algorithm” – under section “Create Static Crypto Maps”
- “You must choose the null integrity algorithm if AES-GCM/GMAC has been configured as the encryption algorithm” – under section “Create Static Crypto Maps”
For the ikev2 policy, this is fairly simple because the only allowable integrity method is “null” when encryption type is set to aes-gcm-*. Because the software enforces this requirement, there is no need to clarify the ambiguity in the documentation.
For the ipsec ipsec-proposal, this still remains confusing to me. When the esp encryption is set to aes-gcm-*, the ASA software allows configuration of integrity types other than “null” … this seems to be in violation of the documentation which states “YOU MUST CHOOSE THE NULL INTEGRITY ALGORITHM [when encrypting with aes-gcm-*].” There is an example further down in the documentation that seems to suggest the correct usage of aes-gcm proposal with null integrity algorithm specified.
ciscoasa(config)# show run crypto ipsec
crypto ipsec ikev2 ipsec-proposal GCM
protocol esp encryption aes-gcm
protocol esp integrity null
I think I may need to fall back on a more basic question like: “What is the AES-GCM cipher is and why would I want to use it?” According to a Wikipedia article, the Galois/Counter Mode (GCM) is “adopted because of its efficiency and performance“ and is “designed to provide both data authenticity (integrity) and confidentiality.“ This would explain why we use “null” integrity under ESP configuration – the integrity is already built into the encryption algorithm. Any integrity method specified for a GCM ESP session would be adding overhead because GCM is already providing message authentication for the encrypted channel. Because the ASA allows an integrity method to be specified here, I think this is allowing users to mis-configure the device ESP and establish tunnels with performance-reducing double integrity checks.
Update for ASA 7.1 software. When configuring aes-gcm* for esp, there is an informative message regarding esp integrity selection: “WARNING: GCM\GMAC are authenticated encryption algorithms. esp integrity config is ignored.” This helps explain that if the peers negotiate gcm for the security association, then none of the configured integrity methods will be used.
Regarding why we want to use it, the same article states: “GCM can take full advantage of parallel processing.” This is the real reason we want to use GCM – it’s FASTER THAN TRADITIONAL AES ON MULTI-CORE NETWORK DEVICES! There appears to be no real security advantage of AES-GCM over AES-CBC. The original AES Cipher Block Chain was designed as a sequential algorithm best suited to execution in a single process (single-core hardware utilization). This distinction makes traditional AES a good choice on single-core devices. AES-GCM should be considered for performance and throughput improvements on multi-core network hardware. Even on systems with less cores, GCM may be a good choice if a multi-core or pipelined cryptography accelerator module is used to provide high-performance gcm cipher features for your IPSec traffic.
A side note, the Wikipedia article also explains that GMAC is “an authentication-only variant of the GCM.” In my opinion, Cisco should make it clear to customers that GMAC DOES NOT ENCRYPT YOUR DATA!!! Because of this, I recommend that Cisco ASA users avoid the use of the GMAC non-cipher. Good news is that gmac is not available under your ikev2 policy. Unfortunately the gmac is a selection under your ipsec-proposal, so please avoid it if you want your data to remain private!!