AAD makes GCM encryption more secure

introduction

This document explains why users may not be able to use a Federal Information Processing Standard (FIPS) -enabled client to connect to an Adaptive Security Appliance (ASA) that has a policy that supports FIPS-enabled encryption algorithms.

Background information

When setting up an IKEv2 connection (Internet Key Exchange Version 2), the initiator never knows which suggestions will be accepted by the peer. The initiator must therefore guess which Diffie-Hellman (DH) group to use when sending the first IKE message. The DH group used for this estimate is usually the first DH group in the list of configured DH groups. The initiator then calculates key data for the guessed groups, but also sends a full list of all groups to the peer so that the peer can select another DH group if the guessed group is wrong.

A client does not have a user-configured list of IKE policies. Instead, there is a preconfigured list of policies that the client supports. For this reason, the list of DH groups has been ordered from weakest to strongest in order to reduce the computational load on the client if you calculate the key data for the first message with a possibly wrong group. The client therefore selects the least computationally intensive DH and thus the least resource-intensive group for the initial estimate, but then switches to the group selected by the headend in subsequent messages.

Note: This behavior differs from the AnyConnect version 3.0 clients, which took the DH groups from strongest to weakest.

At the headend, however, the first DH group in the list sent by the client that matches a DH group configured on the gateway is the selected group. Therefore, if the ASA has also configured weaker DH groups, it will use the weakest DH group supported by the client and configured on the headend, despite the availability of a more secure DH group at both ends.

This behavior was corrected on the client using Cisco Bug ID CSCub92935. Any version of the client that has this bug fixed reverse the order in which DH groups are listed when they are sent to the headend. However, to avoid a backward compatibility issue with gateways other than Suite B, the weakest DH group (one for non-FIPS mode and two for FIPS mode) remains at the top of the list.

Note: After the first entry in the list (group 1 or 2), the groups are listed in the order from strongest to weakest. First the elliptical curve groups (21, 20, 19) and then the modular exponential (MODP) groups (24, 14, 5, 2) are listed.

tip: If the gateway is configured with multiple DH groups in the same policy and it includes group 1 (or 2 in FIPS mode), the ASA will accept the weaker group. The fix is ‚Äč‚Äčthat only DH group 1 is included in a policy configured on the gateway. If multiple groups are configured in a policy but group 1 is not included, the strongest group is selected. Example:

- On ASA version 9.0 (Suite B) with IKEv2 policies set to 1 2 5 14 24 19 20 21, becomes group 1 as expected selected.

- On ASA version 9.0 (Suite B) with IKEv2 policies set to 2 5 14 24 19 20 21, becomes group 21 as expected selected.

- If the client is on ASA version 9.0 (Suite B) in FIPS mode and the IKEv2 policy is set to 1 2 5 14 24 19 20 21, becomes group 2 as expected selected.

- If the tested client is running on ASA version 9.0 (Suite B) in FIPS mode and the IKEv2 policy is set to 5 14 24 19 20 21, becomes group 21 as expected selected.

- On ASA version 8.4.4 (except Suite B) with IKEv2 guidelines on 1 2 5 14 becomes group 1 as expected selected.

- On ASA version 8.4.4 (except Suite B) with IKEv2 guidelines on 2 5 14 becomes group 14 as expected selected.

problem

The ASA is configured with the following IKEv2 policies:

crypto ikev2 policy 1
encryption aes-gcm-256
integrity null
group 20
prf sha384 sha
lifetime seconds 86400
crypto ikev2 policy 10
encryption aes-192
integrity sha
group 5 2
prf sha
lifetime seconds 86400
crypto ikev2 policy 20
encryption aes
integrity sha
group 5 2
prf sha
lifetime seconds 86400

In this configuration, policy 1 is uniquely configured to support all FIPS-enabled encryption algorithms. However, when a user tries to connect through a FIPS-enabled client, the connection fails with the error message:

The cryptographic algorithms required by the secure gateway do not match those
supported by AnyConnect. Please contact your network administrator.

However, if the administrator changes Policy1 to use DH group 2 instead of 20, the connection works.

solution

Based on the symptoms, the first conclusion is that the client will only support DH group 2 when FIPS is enabled and none of the others are working. That is actually wrong. If you enable this debugging on the ASA, you will see the suggestions sent by the client:

debug crypto ikev2 proto 127

When trying to connect, the first debugging message is:

IKEv2-PROTO-2: Received Packet [From 192.168.30.5:51896/To 192.168.30.2:500/
VRF i0: f0]
Initiator SPI: 74572B8D1BEC5873 - Responder SPI: 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUESTIKEv2-PROTO-3: Next payload: SA, version:
2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 747
Payload contents:
SA Next payload: KE, reserved: 0x0, length: 316
last proposal: 0x2, reserved: 0x0, length: 140
Proposal: 1, Protocol id: IKE, SPI size: 0, #trans: 15 last transform: 0x3,
reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-GCM
last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-GCM
last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-GCM
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA512
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA384
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA256
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA1
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: None
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_1024_MODP / Group 2
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_521_ECP / Group 21
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_384_ECP / Group 20
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_256_ECP / Group 19
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP_256_PRIME / Group 24
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP / Group 14
last transform: 0x0, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_1536_MODP / Group 5
last proposal: 0x0, reserved: 0x0, length: 172
Proposal: 2, Protocol id: IKE, SPI size: 0, #trans: 19 last transform: 0x3,
reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-CBC
last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-CBC
last transform: 0x3, reserved: 0x0: length: 12
type: 1, reserved: 0x0, id: AES-CBC
last transform: 0x3, reserved: 0x0: length: 8
type: 1, reserved: 0x0, id: 3DES
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA512
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA384
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA256
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA1
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA512
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA384
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA256
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA96
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_1024_MODP / Group 2
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_521_ECP / Group 21
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_384_ECP / Group 20
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_256_ECP / Group 19
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP_256_PRIME / Group 24
last transform: 0x3, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP / Group 14
last transform: 0x0, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_1536_MODP / Group 5
KE Next payload: N, reserved: 0x0, length: 136
DH group: 2, Reserved: 0x0

fc c9 90 2b 15 35 31 34 0e 75 88 c0 f9 2a 1e 0a
a5 6b e3 8e e1 73 b9 d1 56 1e 60 9f 82 71 6c 4e
5c 1c a4 bd b5 23 a2 bc 82 f2 11 17 61 28 33 3f
02 c9 e7 cb f7 84 a6 22 4a 64 eb fa d7 84 a1 d9
ad c7 5d 77 cd 2a 65 79 95 9a d4 5c 22 8c 62 ae
0e fc c8 fd bd c8 4d 66 0d c3 69 d3 c4 cb e8 33
72 1a f1 cc 31 5f 08 75 65 6b 77 3b 23 c3 b8 74
02 fa 15 6e e4 7a b2 73 17 8f 08 02 20 7e b8 d7
N Next payload: VID, reserved: 0x0, length: 24

87 4d 63 76 cc 10 30 0e 4c 95 40 24 d3 b3 3b f3
44 be 0f e5

Therefore, even though the client sent groups 2, 21, 20, 19, 24, 14, and 5 (these FIPS-compliant groups), the headend still only connects to group 2, which was enabled in policy 1 of the previous configuration is. This problem becomes clear further down in the debugger:

IKEv2 received all requested SPIs from CTM to respond to a tunnel request.
IKEv2-PROTO-5: (64): SM Trace-> SA: I_SPI = 74572B8D1BEC5873 R_SPI = E4160C492A824B5F
(R) MsgID = 00000006 CurState: R_VERIFY_AUTH Event: EV_OK_RECD_IPSEC_RESP
IKEv2-PROTO-2: (64): Processing IKE_AUTH message
IKEv2-PROTO-1: Tunnel Rejected: Selected IKEv2 encryption algorithm (AES-CBC-192)
is not strong enough to secure proposed IPsec encryption algorithm (AES-GCM-256).

IKEv2-PROTO-1: (64): Failed to find a matching policy
IKEv2-PROTO-1: (64): Received Policies:
ESP: Proposal 1: AES-GCM-256 AES-GCM-192 AES-GCM-128 None Don't use ESN

ESP: Proposal 2: AES-CBC-256 AES-CBC-192 AES-CBC-128 3DES SHA512 SHA384 SHA256 SHA96
Don't use ESN

IKEv2-PROTO-1: (64): Failed to find a matching policy
IKEv2-PROTO-1: (64): Expected Policies:
ESP: Proposal 0: AES-GCM-256 SHA384 Don't use ESN

IKEv2-PROTO-5: (64): Failed to verify the proposed policies
IKEv2-PROTO-1: (64): Failed to find a matching policy

The connection fails due to a combination of factors:

  1. When FIPS is enabled, the client only sends certain policies that need to be matched. Under these guidelines, only AES encryption (Advanced Encryption Standard) with a key length greater than / equal to 256 is suggested.

  2. The ASA is configured with several IKEv2 policies, two of which are enabled for Group 2. As previously described, in this scenario the policy that Group 2 has enabled will be used for the connection. However, the encryption algorithm for both policies uses a key size of 192, which is too small for a FIPS-enabled client.

Therefore in this case the ASA and client behave as in the configuration. There are three ways to work around this problem for FIPS-enabled clients:

  1. Configure only one policy with the suggestions you want.

  2. If multiple suggestions are required, do not configure any with Group 2. otherwise one is always selected.

  3. If group 2 needs to be activated, make sure that the correct encryption algorithm is configured (Aes-256 or aes-gcm-256).