セキュリティ : Cisco ASA 5500-X シリーズ次世代型ファイアウォール

AnyConnect クライアントはサポートされていない暗号化アルゴリズムについて FIP が有効に なるとき不平を言います

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 24 日) | フィードバック

概要

ユーザが連邦情報処理標準(FIP)の使用となぜ接続できないかもしれませんかこの資料に-イネーブルになったクライアント記述されていますポリシーがある適応性があるセキュリティ アプライアンス モデル(ASA)に、FIPS 有効に された 暗号 アルゴリズムをサポートする。

著者:Cisco TAC エンジニア、Atri Basu

背景説明

インターネット鍵交換 バージョン 2 (IKEv2)接続設定の間に、発信側は最初の IKE メッセージが送信 されるときどんな提案がピアによって受諾可能である、従って発信側は使用するべきかどの Diffie-Hellman (DH) グループを推測する必要がありますか決してに気づいていません。 この推測に使用する DH グループは通常設定される DH グループのリストの最初の DH グループです。 発信側はそれから推測されたグループが間違っている場合推測されたグループのためのキーデータを計算しますが、またピアにピアが別の DH グループを選択するようにするすべてのグループの完全なリストを送ります。

クライアントの場合には、IKE ポリシーのユーザ設定リストがありません。 その代り、クライアントがサポートするポリシーの前もって構成されたリストがあります。 このような理由で可能性のある間違ったものであるグループの最初のメッセージのためのキーデータを計算するとき、クライアントのコンピュータ の 負荷を減らすために、DH グループのリストは最も弱いから最も強いへの発注されました。 従って従って、クライアントは最初の推測のための最少コンピュータ集約 DH および最少リソース集中型 グループを選択しますが、それ以降のメッセージのヘッドエンドによって選択されるグループに一方では切り替えます。

: この動作は最も強いから最も弱いに DH グループを発注した AnyConnect バージョン 3.0 クライアントと異なっています。

ただし、ヘッドエンドで、一致するクライアントが送信 するリストの最初の DH グループは選択されるゲートウェイで設定される DH グループ グループです。 従って、ASA にまた設定されるより弱い DH グループがあればクライアントによってサポートされ、両端のセキュア DH グループのアベイラビリティにもかかわらずヘッドエンドで設定されるそれは最も弱い DH グループを使用します。

この動作は Cisco バグ ID CSCub92935 によるクライアントで固定されました。 この不具合からの修正が付いているすべてのクライアントバージョンはヘッドエンドに送信 されるとき DH グループがリストされている順序を反転させます。 ただし、非スイート B ゲートウェイにおいての逆方向互換性問題を避けるために、最も弱い DH グループ(1 および FIP モードのための非 FIPS モードのための 2)はリストの上に残ります。

: リストの最初のエントリ後(グループ 1 はまたは 2)、グループ最も弱いに最も強いの順でリストされています。 これは楕円曲線グループ第 1 を置きます(21、19) モジュラ指数(MODP 先行させている) 20、グループが(24、14、5、2)。

ヒント: ゲートウェイが同じポリシーの複数の DH グループで設定され、FIP モードのグループ 1 (または 2)が含まれていれば、ASA はより弱いグループを受け入れます。 修正はゲートウェイで設定されるポリシーに DH グループ 1 を単独で含めることです。 複数のグループが 1 ポリシーで設定されるが、グループ 1 が含まれていないとき、最も強いの選択されます。 次に、例を示します。

- ASA バージョン 9.0 で… (1 2 5 14 24 19 20 21 への IKEv2 ポリシー セットが付いているスイート B)は、グループ 1 予想通り選択されます

- ASA バージョン 9.0 で… (2 5 14 24 19 20 21 への IKEv2 ポリシー セットが付いているスイート B)は、グループ 21 予想通り選択されます

- ASA バージョン 9.0 の FIP モードのクライアントと… (1 2 5 14 24 19 20 21 への IKEv2 ポリシー セットが付いているスイート B)は、グループ 2 予想通り選択されます

- ASA バージョン 9.0 の FIP モードのテストされたクライアントと… (5 14 24 19 20 21 への IKEv2 ポリシー セットが付いているスイート B)は、グループ 21 予想通り選択されます

- ASA バージョン 8.4.4 で… (1 2 5 14 への IKEv2 ポリシー セットが付いている非スイート B)は、グループ 1 予想通り選択されます

- ASA バージョン 8.4.4 で… (2 5 14 への IKEv2 ポリシー セットが付いている非スイート B)は、グループ 14 予想通り選択されます

問題

ASA はこれらの IKEv2 ポリシーで設定されます:

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

この設定ではすべての FIPS 有効に された 暗号化アルゴリズムをサポートするために、ポリシー 1 は明確に設定されます。 ただし、ユーザが FIPS 有効に された クライアントから接続することを試みるとき接続はエラーメッセージと失敗します:

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

ただし 20 の代りに DHグループ2 を使用するように、admin が policy1 を変更すれば、接続ははたらきます。

解決策

現象に基づいて、最初の結論は FIP が有効に なり、他のどれもはたらかないときだけクライアントが DHグループ2 をサポートすることです。 これは実際に不正確です。 ASA のこのデバッグを有効に する場合、クライアントが送信 する提案を次のように表示できます:

debug crypto ikev2 proto 127

接続の試みの間に、最初のデバッグ メッセージは次のとおりです:

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

従って、クライアントがグループ 2,21,20,19,24,14 および 5 を(これらの FIPS 対応グループ)送信 したにもかかわらず、ヘッドエンドはまだ以前のコンフィギュレーションのポリシー 1 で 2 有効に なる グループだけ接続しません。 この問題はデバッグの明白なそれ以上のダウンになります:

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

接続はファクタの組み合せが理由で失敗します:

  1. 有効に されて FIP がクライアント送信特定のポリシーおよびそれらだけ一致する必要があります。 それらのポリシーの間で、それは 256 に等しい、 またはそれ以上のキーサイズの Advanced Encryption Standard (AES) 暗号化だけを提案します。

  2. ASA は 2 つに有効に なる グループ 2 がある複数の IKEv2 ポリシーで設定されます。 ポリシーが接続のために有効に なる グループ 2 がある使用されること、このシナリオに先に説明があられる。 ただし、それらのポリシーの両方の暗号化アルゴリズムは FIPS 有効に された クライアントのために余りに低い 192 のキーサイズを使用します。

従って、この場合、ASA およびクライアントは設定によって動作します。 回避策へ 3 つの方法が FIPS 有効に された クライアントのためのこの問題あります:

  1. 望まれる正確な提案で 1 ポリシーだけ設定して下さい。

  2. 複数の提案が必要となる場合、グループ 2 で 1 つを設定しないで下さい; さもなければそのは常に選択されます。

  3. グループ 2 が有効に する必要がある場合右の暗号化アルゴリズムを設定してもらうことを確認して下さい(Aes-256 か aes-gcm-256)。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 118427