Cisco Cisco AnyConnect Secure Mobility Client v2.x Troubleshooting Guide
AnyConnect Client Complains About Unsupported
Cryptographic Algorithms When FIPS is Enabled
Cryptographic Algorithms When FIPS is Enabled
Document ID: 118427
Contributed by Atri Basu, Cisco TAC Engineer.
Nov 07, 2014
Nov 07, 2014
Contents
Introduction
Background Information
Problem
Solution
Background Information
Problem
Solution
Introduction
This document describes why users might not be able to connect with the use of a Federal Information
Processing Standard (FIPS)−enabled client to an Adaptive Security Appliance (ASA), which has a policy that
supports FIPS−enabled crypto algorithms.
Processing Standard (FIPS)−enabled client to an Adaptive Security Appliance (ASA), which has a policy that
supports FIPS−enabled crypto algorithms.
Background Information
During an Internet Key Exchange Version 2 (IKEv2) connection set up, the initiator is never aware of what
proposals are acceptable by the peer, so the initiator must guess which Diffie−Hellman (DH) group to use
when the first IKE message is sent. The DH group used for this guess is usually the first DH group in the list
of DH groups configured. The initiator then computes key data for the guessed groups but also sends a
complete list of all groups to the peer, which allows the peer to select a different DH group if the guessed
group is wrong.
proposals are acceptable by the peer, so the initiator must guess which Diffie−Hellman (DH) group to use
when the first IKE message is sent. The DH group used for this guess is usually the first DH group in the list
of DH groups configured. The initiator then computes key data for the guessed groups but also sends a
complete list of all groups to the peer, which allows the peer to select a different DH group if the guessed
group is wrong.
In case of a client, there is no user−configured list of IKE policies. Instead, there is a preconfigured list of
policies that the client supports. Because of this, in order to reduce the computational load on the client when
you calculate the key data for the first message with a group that is possibly the wrong one, the list of DH
groups was ordered from weakest to strongest. Thus, the client chooses the least computationally−intensive
DH and therefore the least resource−intensive group for the initial guess, but then switches over to the group
chosen by the headend in subsequent messages.
policies that the client supports. Because of this, in order to reduce the computational load on the client when
you calculate the key data for the first message with a group that is possibly the wrong one, the list of DH
groups was ordered from weakest to strongest. Thus, the client chooses the least computationally−intensive
DH and therefore the least resource−intensive group for the initial guess, but then switches over to the group
chosen by the headend in subsequent messages.
Note: This behavior is different from AnyConnect Version 3.0 clients that ordered the DH groups from
strongest to weakest.
strongest to weakest.
However, on the headend, the first DH group on the list sent by the client that matches a DH group configured
on the gateway is the group that is selected. Therefore, if the ASA also has weaker DH groups configured, it
uses the weakest DH group that is supported by the client and configured on the headend despite the
availability of a more secure DH group on both ends.
on the gateway is the group that is selected. Therefore, if the ASA also has weaker DH groups configured, it
uses the weakest DH group that is supported by the client and configured on the headend despite the
availability of a more secure DH group on both ends.
This behavior was fixed on the client through Cisco bug ID CSCub92935. All client versions with the fix
from this bug reverse the order in which DH groups are listed when they are sent to the headend. However, in
order to avoid a backwards−compatibility issue with non−Suite B gateways, the weakest DH group (one for
non−FIPS mode and two for FIPS mode) remains at the top of the list.
from this bug reverse the order in which DH groups are listed when they are sent to the headend. However, in
order to avoid a backwards−compatibility issue with non−Suite B gateways, the weakest DH group (one for
non−FIPS mode and two for FIPS mode) remains at the top of the list.