セキュリティと VPN : Internet Security Association and Key Management Protocol(ISAKMP)

IOS 多重 認証とのプロファイルのための IKEv1 および IKEv2 パケット交換プロセス

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

概要

この資料は証明書認証がおよび発生するかもしれない考えられる 問題使用されるときインターネット鍵交換バージョン 1 (IKEv1)およびインターネット鍵交換 バージョン 2 (IKEv2)パケット交換プロセスを説明したものです。

この資料に説明があるサブジェクトのリストはここにあります:

  • インターネット キー エクスチェンジ(IKE) 発信側および IKE 応答側のための証明書選択基準
  • 複数の IKE プロファイルが一致する場合の IKE プロファイル一致条件(オーバーラップおよび非オーバーラップ シナリオのために)
  • 信頼ポイントが IKE プロファイルの下で使用されない場合のデフォルト設定および動作
  • プロファイルおよび証明書選択基準に関する IKEv1 と IKEv2 の違い

: 特定の問題を解決する方法についての詳細については正しいセクションを参照して下さい。 また、概略はこの資料の終わりに提供されます。


著者:Cisco TAC エンジニア、Michal Garcarz

前提条件


要件

次の項目に関する知識があることが推奨されます。

  • Cisco IOS ® VPN 設定
  • IKEv1 および IKEv2 プロトコル(パケット交換)

使用するコンポーネント

この文書に記載されている情報は Cisco IOS Version15.3T に基づいています。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。


背景説明

この資料に説明がある問題は複数の信頼ポイントおよび複数の IKE プロファイルが使用されるとき起こります。

この資料で使用する最初の例に各ルータの 2 信頼ポイントが付いている IKEv1 LAN-to-LAN トンネルがあります。 最初は、それは設定が正しいことにようであるかもしれません。 ただし、VPN トンネルはカリフォルニア信頼点のコマンドがローカル ストアで Internet Security Association and Key Management Protocol(ISAKMP) プロファイル 動作と登録された認証の発注のために使用される方法が理由で接続の一方からだけ開始することができます。

異なる動作は ISAKMP プロファイルのためのカリフォルニア信頼点のコマンドでルータが ISAKMP 発信側のとき設定されます。 プロファイルのために設定される問題は ISAKMP 発信側が ISAKMP プロファイル初めからに気づいている、従ってカリフォルニア信頼点のコマンドはメインモード パケット 3 (MM3)の証明書要求のためのペイロードに影響を及ぼすことができますので発生するかもしれません。 ただし、ルータは ISAKMP 応答側のとき、バインドを作成して必要である IKE ID が含まれているメインモード パケット 5 (MM5)を受信した後仕様 ISAKMP プロファイルに着信 トラフィックを結合 します。 こういうわけでプロファイルが MM5 の前に判別されないのでメインモード パケット 4 (MM4)パケットのためのカリフォルニア信頼点のコマンドを適用することはできません。

MM3 および MM4 の認証 requestpayload および影響全体的に見るとネゴシエーションプロセスの順序は接続だけが VPN トンネルの一方から確立されるようにするという原因、またこの資料で、説明されます。

IKEv1 発信側および応答側 動作の概略はここにあります:


 IKEv1 発信側IKEv1 応答側
送信要求プロファイルの下で設定される信頼ポイントのためのだけ特定の要求を送信 します 利用可能 な信頼ポイントすべてのための送信要求
要求を検証して下さいプロファイルの下で設定される特定の信頼ポイントに対して検証しますプロファイルの下で設定される特定の信頼ポイントに対して検証します


Cisco は複数の ISAKMP プロファイルがあり、グローバルに設定された信頼ポイントを使用する ISAKMP レスポンダーにカリフォルニア信頼点のコマンドを使用しないことを推奨します。 複数の ISAKMP プロファイルの ISAKMP 開始プログラムに関しては、Cisco は各プロファイルのカリフォルニア信頼点のコマンドで証明書選択プロセスを狭くすることを推奨します。

IKEv2 プロトコルに IKEv1 プロトコルと同じ問題がありますが、PKI トラストポイント コマンド ヘルプの異なる動作は問題の発生を防ぎます。 これはカリフォルニア信頼点のコマンドは IKEv1 発信側のためにオプションであるが PKI トラストポイント コマンドが IKEv2 発信側のために必須であるという理由によります。 ある状況下では(1 プロファイル以下の複数の信頼ポイント)、以前に記述されていた問題は発生するかもしれません。 従って、Cisco は接続(IKEv2 プロファイルの両方の下で設定される同じ信頼ポイント)の両側のために対称信頼点のコンフィギュレーションを使用することを推奨します。


トポロジ

これはこの資料で例すべてのために使用する一般的 な トポロジーです。


: ルータ 1 (R1)およびルータ 2 (R2)使用 仮想 な トンネルインターフェイス(VTIs)ループバックにアクセスするため。 これらの VTIs は IPSec によって保護されます。


この IKEv1 例に関しては、各ルータは各認証局 (CA)のための 2 信頼ポイントを備え、信頼ポイントのそれぞれのための認証は登録されます。

R1 が ISAKMP 発信側のとき、トンネルは正しくネゴシエートし、トラフィックは保護されます。 これは正常な動作です。 R2 が ISAKMP 発信側のとき、Phase1 ネゴシエーションは失敗します。


: この資料の IKEv2 例に関しては、トポロジーおよびアドレッシングは IKEv1 例を示されている同じとです。


パケット交換 プロセス

このセクションはパケット交換 プロセスのために使用する、および起こるかもしれない考えられる 問題記述します IKEv1 をおよび IKEv2 設定バリエーション。


多重 認証との IKEv1

多重 認証との IKEv1 のための R1 ネットワークおよび VPN 設定はここにあります:


crypto isakmp policy 10
 encr 3des
 hash md5
 group 2

crypto isakmp profile prof1
   self-identity fqdn
   ca trust-point IOSCA1
   match identity host R2.cisco.com
!
crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile prof1
 set transform-set TS
 set isakmp-profile prof1         
!
interface Loopback0
 description Simulate LAN
 ip address 192.168.100.1 255.255.255.0
!
interface Tunnel1
 ip address 10.0.0.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.2
 tunnel protection ipsec profile prof1
!
interface Ethernet0/0
 ip address 192.168.0.1 255.255.255.0

ip route 192.168.200.0 255.255.255.0 10.0.0.2

多重 認証との IKEv1 のための R2 ネットワークおよび VPN 設定はここにあります:


crypto isakmp policy 10
 encr 3des
 hash md5
 group 2

crypto isakmp profile prof1
   self-identity fqdn
   match identity host R1.cisco.com
!
crypto ipsec transform-set TS esp-aes esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile prof1
 set transform-set TS
 set isakmp-profile prof1
!
interface Loopback0
 ip address 192.168.200.1 255.255.255.0
!
interface Tunnel1
 ip address 10.0.0.2 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.1
 tunnel protection ipsec profile prof1
!
interface Ethernet0/0
 ip address 192.168.0.2 255.255.255.0

ip route 192.168.100.0 255.255.255.0 10.0.0.1

この例では、R1 に 2 信頼ポイントがあります: 1 つは IOSCA1 および第 2 使用 IOSCA2 を使用します:


crypto pki trustpoint IOSCA1
 enrollment url http://192.168.0.3:80
 serial-number
 fqdn R1.cisco.com
 ip-address 192.168.0.1
 subject-name CN=R1,OU=IT,O=cisco,O=com
 revocation-check crl
!
crypto pki trustpoint IOSCA2
 enrollment url http://192.168.0.4:80
 serial-number
 fqdn R1.cisco.com
 ip-address 192.168.0.1
 subject-name CN=R1,OU=IT,O=cisco,O=com
 revocation-check crl

この例では、R2 にまた 2 信頼ポイントがあります: 1 つは IOSCA1 および第 2 使用 IOSCA2 を使用します:


crypto pki trustpoint IOSCA1
 enrollment url http://192.168.0.3:80
 serial-number
 fqdn R2.cisco.com
 ip-address 192.168.0.2
 subject-name CN=R2,OU=IT,O=cisco,O=com
 revocation-check crl
!
crypto pki trustpoint IOSCA2
 enrollment url http://192.168.0.4:80
 serial-number
 fqdn R2.cisco.com
 ip-address 192.168.0.2
 subject-name CN=R2,OU=IT,O=cisco,O=com
 revocation-check crl

これらのコンフィギュレーションの単一違いに注意することは重要です: R1 ISAKMP プロファイルは信頼点の示す IOSCA1 に R1 は信頼点のその仕様によって検証される認証だけ信頼することをカリフォルニア信頼点のコマンドを使用します。 それに対して、R2 はグローバルに定義されした信頼ポイントすべて検証される認証すべてを信頼します。


IKEv1 発信側として R1

R1 および R2 両方のためのデバッグ・コマンドはここにあります:

  • R1# debug crypto isakmp
  • R1# debug crypto ipsec
  • R1# debug crypto PKI 検証

ここでは、R1 はトンネルを開始し、認証 requestin を MM3 送信 します:


*Jun 20 13:00:37.609: ISAKMP:(0): SA request profile is prof1
*Jun 20 13:00:37.610: ISAKMP (0): constructing CERT_REQ for issuer
 cn=CA1,o=cisco,o=com

*Jun 20 13:00:37.610: ISAKMP:(0): sending packet to 192.168.0.2
 my_port 500 peer_port 500 (I) MM_SA_SETUP
*Jun 20 13:00:37.610: ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM3

パケットが信頼点の IOSCA1 のためだけである 1 つの証明書要求だけ含まれていることに注意することは重要です。 これは ISAKMP プロファイル(CN=CA1、O=cisco、O=com)の現在のコンフィギュレーションを用いる予期された動作です。 組み込みパケットキャプチャ 機能と確認できる他の証明書要求は送信 されません、:



R2 はパケットを受信するとき、信頼点を判別するおよび MM5 で認証のために使用する関連する認証を作成するマッチ証明書要求を処理し始めます。 プロセス順序は ISAKMPパケットの証明書要求 ペイロードと同じです。 これは最初の一致が使用されることを意味します。 このシナリオでは、R1 が特定の信頼点で設定され、信頼点と関連付けられる 1 証明書要求だけ送信 するので一致する 1 だけがあります。


*Jun 20 13:00:37.617: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.617: ISAKMP:(1010): peer wants cert issued
 by cn=CA1,o=cisco,o=com
*Jun 20 13:00:37.617:  Choosing trustpoint IOSCA1 as issuer

その後、R2 は MM4 を準備します。 信頼された信頼ポイントすべてのための証明書要求が含まれているこれはパケットです。 R2 が ISAKMP 応答側であるので、グローバルに定義されした信頼ポイントすべては信頼されます(カリフォルニア信頼点の設定はチェックされません)。 信頼ポイントの 2 つは(IOSCA1 および IOSCA2)手動で定義され、他はあらかじめ定義されます。


*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=CA1,o=cisco,o=com
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=CA2,o=cisco,o=com
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer ou=Class 3 Public Primary Certification Authority,
 o=VeriSign, Inc.,c=US

*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=Cisco SSCA2,o=Cisco Systems
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=Cisco Manufacturing CA,o=Cisco Systems
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=Cisco Root CA 2048,o=Cisco Systems
*Jun 20 13:00:37.617: ISAKMP (1010): constructing CERT_REQ
 for issuer cn=Cisco Root CA M1,o=Cisco
*Jun 20 13:00:37.617: ISAKMP:(1010): sending packet to
 192.168.0.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH
*Jun 20 13:00:37.617: ISAKMP:(1010):Sending an IKE IPv4 Packet.
*Jun 20 13:00:37.617: ISAKMP:(1010):Input = IKE_MESG_INTERNAL,
 IKE_PROCESS_COMPLETE
*Jun 20 13:00:37.617: ISAKMP:(1010):Old State = IKE_R_MM3
 New State = IKE_R_MM4

Wireshark のパケットを確認できます。 R2 からの MM4 パケットは 7 つの証明書要求 エントリが含まれています:



それから、R1 は多重 認証 要求フィールドとの R2 から MM4 を受け取ります:


*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=CA1,o=cisco,o=com

*Jun 20 13:00:37.623: ISAKMP: Examining profile list for trustpoint IOSCA1
*Jun 20 13:00:37.623: ISAKMP: Found matching profile for IOSCA1
*Jun 20 13:00:37.623:  Choosing trustpoint IOSCA1 as issuer
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=CA2,o=cisco,o=com
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by ou=Class 3
 Public Primary Certification Authority,o=VeriSign, Inc.,c=US

*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=Cisco SSCA2,o=Cisco Systems
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=Cisco Manufacturing CA,o=Cisco Systems
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=Cisco Root CA 2048,o=Cisco Systems
*Jun 20 13:00:37.623: ISAKMP:(1010): processing CERT_REQ payload. message ID = 0
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants a CT_X509_SIGNATURE cert
*Jun 20 13:00:37.623: ISAKMP:(1010): peer wants cert issued by
 cn=Cisco Root CA M1,o=Cisco

R1 の最初の一致ルールは信頼点の IOSCA1 に最初の証明書要求をマッチさせます。 これは R1 が MM5 の認証のための信頼点の IOSCA1 と関連付けられる認証を使用することを判別します。 完全修飾ドメイン名 (FQDN)は IKE ID として使用されます。 これは ISAKMP プロファイルの自己識別 fqdn 設定が原因です:


*Jun 20 13:00:37.624: ISAKMP (1010): constructing CERT payload for serialNumber=
 100+ipaddress=192.168.0.1+hostname=R1.cisco.com,cn=R1,ou=IT,o=cisco,o=com
*Jun 20 13:00:37.624: ISAKMP:(1010): using the IOSCA1 trustpoint's
 keypair to sign

MM5 は R2 によって受け取られ、処理されます。 受け取った IKE ID (R1.cisco.com)は ISAKMP プロファイル prof1 と一致します。 受け取った認証はそれから検証され、認証は正常です:


*Jun 20 13:00:37.625: ISAKMP:(1010): processing ID payload. message ID = 0
*Jun 20 13:00:37.625: ISAKMP (1010): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : R1.cisco.com
        protocol     : 17
        port         : 500
        length       : 20
*Jun 20 13:00:37.625: ISAKMP:(0):: peer matches prof1 profile
..........
*Jun 20 13:00:37.626: CRYPTO_PKI: (A0013) Certificate validation succeeded
..........
*Jun 20 13:00:37.626: ISAKMP:(1010):SA authentication status:
        authenticated

それから、R2 は IOSCA1 と関連付けられる認証との MM6 を準備します:


*Jun 20 13:00:37.627: ISAKMP (1010): constructing CERT payload for serialNumber=
 101+ipaddress=192.168.0.2+hostname=R2.cisco.com,cn=R2,ou=IT,o=cisco,o=com
*Jun 20 13:00:37.627: ISAKMP:(1010): using the IOSCA1 trustpoint's keypair to sign
*Jun 20 13:00:37.632: ISAKMP:(1010): sending packet to 192.168.0.1
 my_port 500 peer_port 500 (R) MM_KEY_EXCH

パケットは R1 によって受信され、R1 は認証および認証を確認します:


*Jun 20 13:00:37.632: ISAKMP (1010): received packet from 192.168.0.2
 dport 500 sport 500 Global (I) MM_KEY_EXCH
*Jun 20 13:00:37.632: ISAKMP:(1010): processing ID payload. message ID = 0
*Jun 20 13:00:37.632: ISAKMP (1010): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : R2.cisco.com
        protocol     : 17
        port         : 500
        length       : 20
....
*Jun 20 13:00:37.632: ISAKMP:(0): Creating CERT validation list: IOSCA1
....
*Jun 20 13:00:37.633: CRYPTO_PKI: (80013) Certificate validation succeeded
....
*Jun 20 13:00:37.637: ISAKMP:(1010):SA authentication status:
        authenticated
*Jun 20 13:00:37.637: ISAKMP:(1010):Old State = IKE_I_MM6
 New State = IKE_P1_COMPLETE

これは 1.フェーズ 2 がいつも通りネゴシエートされるフェーズを完了します。 トンネルはうまく確立され、トラフィックは保護されます。


IKEv1 発信側として R2

この例は R2 が同じ IKEv1 トンネルを開始し、それがなぜ確立されないか説明するときプロセスを説明したものです。


: ログの部分は前のセクションで示される例に関連して違いにだけ焦点を合わせるために取除かれます。


R2 は R2 に ISAKMP プロファイルとの信頼点の準がないので 7 つの証明書要求 ペイロードとの MM3 を送信 します(すべての信頼ポイントは信頼されます):


*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=CA1,o=cisco,o=com

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=CA2,o=cisco,o=com

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer ou=Class 3 Public Primary Certification Authority,
 o=VeriSign, Inc.,c=US

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=Cisco SSCA2,o=Cisco Systems

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=Cisco Manufacturing CA,o=Cisco Systems

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=Cisco Root CA 2048,o=Cisco Systems

*Jun 17 18:08:44.321: ISAKMP (0): constructing CERT_REQ for
 issuer cn=Cisco Root CA M1,o=Cisco

*Jun 17 18:08:44.321: ISAKMP (0): sending packet to 192.168.0.1
 my_port 500 peer_port 500 (I) MM_SA_SETUP

R1 は R2 からパケットを受信するとき、証明書要求を処理し、信頼点の MM6 で送信 される 認証を判別する IOSCA1 を一致します:


*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=CA1,o=cisco,o=com

*Jun 17 18:08:14.321:  Choosing trustpoint IOSCA1 as issuer
*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=CA2,o=cisco,o=com

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 ou=Class 3 Public Primary Certification Authority,o=VeriSign, Inc.,c=US

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=Cisco SSCA2,o=Cisco Systems

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=Cisco Manufacturing CA,o=Cisco Systems

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=Cisco Root CA 2048,o=Cisco Systems

*Jun 17 18:08:14.321: ISAKMP:(1099): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:14.321: ISAKMP:(1099): peer wants cert issued by
 cn=Cisco Root CA M1,o=Cisco

その後、R1 は証明書要求 ペイロードとの MM4 パケットを準備します。 この場合多重 認証 要求 ペイロードがあります:


*Jun 17 18:08:14.321: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=CA2,o=cisco,o=com

*Jun 17 18:08:14.321: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=CA1,o=cisco,o=com

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 ou=Class 3 Public Primary Certification Authority,
 o=VeriSign, Inc.,c=US

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=Cisco SSCA2,o=Cisco Systems

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=Cisco Manufacturing CA,o=Cisco Systems

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=Cisco Root CA 2048,o=Cisco Systems

*Jun 17 18:08:14.322: ISAKMP (1099): constructing CERT_REQ for issuer
 cn=Cisco Root CA M1,o=Cisco

*Jun 17 18:08:14.322: ISAKMP:(1099): sending packet to 192.168.0.2
 my_port 500 peer_port 500 (R) MM_KEY_EXCH

組み込みパケットキャプチャ(EPC)および Wireshark のログを確認して下さい:



R1 が ISAKMP プロファイルの単一信頼点のために(IOSCA1)設定されるのに、送信 される 多重 認証 要求があります。 これは ISAKMP プロファイルのカリフォルニア信頼点のコマンドが証明書要求 ペイロードを判別するが、ときだけルータが ISAKMP セッションの発信側のので発生します。 ルータが応答側である場合、IKE セッションのために使用する R1 がまだ ISAKMP プロファイルを知っていないのでグローバルに定義されした信頼ポイントすべてのための多重 認証 要求 ペイロードがあります。

受信 IKE セッションは IKE ID がその後含まれている MM5 の受信の後で仕様 ISAKMP プロファイルにプロファイルに、特定のプロファイルのための一致識別コマンド 結合 します IKE セッションを抑制されます。 ただし、ルータはこれを今まで判別できません。 各プロファイルのために設定される異なるカリフォルニア信頼点のコマンドで複数の ISAKMP プロファイルがあるかもしれません。

従って、R1 はグローバルに設定された信頼ポイントすべてのための証明書要求を送信 する必要があります。

カリフォルニア信頼点のコマンドのためのコマンドレファレンスを参照して下さい:

IKE を始めるルータおよび IKE 要求に対応するルータは対称トラストポイントの設定があるはずです。 たとえば、RSA シグニチャ 暗号化および認証を行う対応ルータは(IKE メインモードで) CERT-REQ ペイロードを送信 するときグローバルコンフィギュレーションで定義された trustpoints を使用するかもしれません。 ただし、ルータは証明書確認のための ISAKMP プロファイルで定義された trustpoints の制限リストを使用するかもしれません。 トラストポイントが応答ルータのグローバル リストにない応答ルータの ISAKMP プロファイルにあるが、認証を使用するためにピア(IKE 発信側)が設定されれば、認証は拒否されます。 開始ルータが対応ルータのグローバルコンフィギュレーションの trustpoints について知らなければ、(しかし認証はまだ認証することができます。)

この場合最初の証明書要求 ペイロードを検出するために MM4 パケット詳細を確認して下さい:



MM4 パケットは最初の証明書要求 ペイロードで R1 から送信 される 認証がインストールされている順序が理由で信頼点の IOSCA2 が含まれています; 最初の 1 つは信頼点の IOSCA2 によって署名します:


R1#sh crypto pki certificates 
Certificate
  Status: Available
  Certificate Serial Number (hex): 03
  Certificate Usage: General Purpose
  Issuer:
    cn=CA2
    o=cisco
    o=com
  Subject:
    Name: R1.cisco.com
    IP Address: 192.168.0.1
    Serial Number: 100
    serialNumber=100+ipaddress=192.168.0.1+hostname=R1.cisco.com
    cn=R1
    ou=IT
    o=cisco
    o=com
  Validity Date:
    start date: 13:25:01 CET Jun 17 2013
    end   date: 13:25:01 CET Jun 17 2014
  Associated Trustpoints: IOSCA2
...
<output omitted, 1 more R1 cert signed by CA1, 2 more CA certs>

信頼点の IOSCA1 が最初の証明書要求 ペイロードに含まれているとき R2 から送信 される MM3 パケットとの比較をして下さい:


R2#sh crypto pki certificates 
Certificate
  Status: Available
  Certificate Serial Number (hex): 02
  Certificate Usage: General Purpose
  Issuer:
    cn=CA1
    o=cisco
    o=com
  Subject:
    Name: R2.cisco.com
    IP Address: 192.168.0.2
    Serial Number: 101
    serialNumber=101+ipaddress=192.168.0.2+hostname=R2.cisco.com
    cn=R2
    ou=IT
    o=cisco
    o=com
  Validity Date:
    start date: 13:23:49 CET Jun 17 2013
    end   date: 13:23:49 CET Jun 17 2014
  Associated Trustpoints: IOSCA1
  Storage: nvram:CA1#2.cer
...
<output omitted, 1 more R2 cert signed by CA2, 2 more CA certs>

この場合 R2 は R1 から MM4 パケットを受信し、証明書要求を処理し始めます。 最初の証明書要求 ペイロードは信頼点の IOSCA2 と一致します:


*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=CA2,o=cisco,o=com

*Jun 17 18:08:44.335:  Choosing trustpoint IOSCA2 as issuer
*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=CA1,o=cisco,o=com

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 ou=Class 3 Public Primary Certification Authority,o=VeriSign, Inc.,c=US

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=Cisco SSCA2,o=Cisco Systems

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=Cisco Manufacturing CA,o=Cisco Systems

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=Cisco Root CA 2048,o=Cisco Systems

*Jun 17 18:08:44.335: ISAKMP:(1100): processing CERT_REQ payload.
 message ID = 0
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.335: ISAKMP:(1100): peer wants cert issued by
 cn=Cisco Root CA M1,o=Cisco

R2 は MM5 パケットを準備するとき、信頼点の IOSCA2 と関連付けられる認証を使用します:


*Jun 17 18:08:44.335: ISAKMP:(1100):SA is doing RSA signature authentication
 using id type ID_FQDN
*Jun 17 18:08:44.335: ISAKMP (1100): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : R2.cisco.com
        protocol     : 17
        port         : 500
        length       : 20
*Jun 17 18:08:44.335: ISAKMP:(1100):Total payload length: 20
*Jun 17 18:08:44.335: ISAKMP:(1100): IKE->PKI Get CertificateChain to be sent
 to peer state (I) MM_KEY_EXCH (peer 192.168.0.1)
*Jun 17 18:08:44.335: ISAKMP:(1100): PKI->IKE Got CertificateChain to be sent
 to peer state (I) MM_KEY_EXCH (peer 192.168.0.1)
*Jun 17 18:08:44.336: ISAKMP (1100): constructing CERT payload for
 serialNumber=101+ipaddress=192.168.0.2+hostname=R2.cisco.com,cn=R2,
 ou=IT,o=cisco,o=com

R2#
*Jun 17 18:08:44.336: ISAKMP:(1100): using the IOSCA2 trustpoint's
 keypair to sign

*Jun 17 18:08:44.336: ISAKMP:(1100): sending packet to 192.168.0.1
 my_port 500 peer_port 500 (I) MM_KEY_EXCH
*Jun 17 18:08:44.336: ISAKMP:(1100):Sending an IKE IPv4 Packet.

MM5 パケットは R1 によって受信されます。 R1 が信頼点の IOSCA1 だけ(ISAKMP プロファイル prof1 のために)信頼するので、認証の検証は失敗します:


*Jun 17 18:08:44.337: ISAKMP (1100): received packet from 192.168.0.2
 dport 500 sport 500 Global (R) MM_KEY_EXCH
*Jun 17 18:08:44.337: ISAKMP:(1100):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 17 18:08:44.337: ISAKMP:(1100):Old State =IKE_R_MM4  New State = IKE_R_MM5

*Jun 17 18:08:44.337: ISAKMP:(1100): processing ID payload. message ID = 0
*Jun 17 18:08:44.337: ISAKMP (1100): ID payload
        next-payload : 6
        type         : 2
        FQDN name    : R2.cisco.com
        protocol     : 17
        port         : 500
        length       : 20
*Jun 17 18:08:44.337: ISAKMP:(0):: peer matches prof1 profile
*Jun 17 18:08:44.337: ISAKMP:(1100): processing CERT payload. message ID = 0
*Jun 17 18:08:44.337: ISAKMP:(1100): processing a CT_X509_SIGNATURE cert
*Jun 17 18:08:44.337: ISAKMP:(1100): IKE->PKI Add peer's certificate state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: CRYPTO_PKI: (900C5) Adding peer certificate
*Jun 17 18:08:44.337: ISAKMP:(1100): PKI->IKE Added peer's certificate state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: ISAKMP:(1100): IKE->PKI Get PeerCertificateChain state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: ISAKMP:(1100): PKI->IKE Got PeerCertificateChain state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: ISAKMP:(1100): peer's pubkey isn't cached
*Jun 17 18:08:44.337: ISAKMP:(1100):Profile has no keyring, aborting key search
*Jun 17 18:08:44.337: ISAKMP:(0): Creating CERT validation list: IOSCA1,
*Jun 17 18:08:44.337: ISAKMP:(1100): IKE->PKI Validate certificate chain state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.337: CRYPTO_PKI:ip-ext-val:IP extension validation not required
*Jun 17 18:08:44.341: CRYPTO_PKI: (900C5) Check for identical certs
*Jun 17 18:08:44.341: CRYPTO_PKI: (900C5) Create a list of suitable trustpoints
*Jun 17 18:08:44.341: CRYPTO_PKI: (900C5) No suitable trustpoints found
*Jun 17 18:08:44.341: ISAKMP:(1100): PKI->IKE Validate certificate chain state
 (R) MM_KEY_EXCH (peer 192.168.0.2)
*Jun 17 18:08:44.341: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from
 192.168.0.2 is bad: unknown error returned in certificate validation

R1#
*Jun 17 18:08:44.341: ISAKMP:(1100): Unknown error in cert validation, -1

この設定は最初の表示する 認証が信頼点の IOSCA1 によって署名するので R1 の証明書登録の順序が異なっている場合機能します。 また、MM4 の最初の証明書要求 ペイロードは信頼点の R2 によって選択され、MM6 の R1 で正常に検証される IOSCA1 です。


プロファイルのカリフォルニア信頼点のコマンドのない IKEv1

複数のプロファイルおよび信頼ポイントが付いているしかしプロファイルの特定の信頼点の設定のないシナリオに関しては、カリフォルニア信頼点のコマンド 設定によって判別される特定の信頼ポイントの検証がないので問題がありません。 ただし、選択過程は明らかではないかもしれません。 発信側であるルータに依存は証明書登録の順序に関連して認証プロセスに、異なる認証選択されます。

時々認証は署名するために使用する典型的なハッシュ 関数ではない x509 バージョン 1 ののような接続の一方だけによって、サポートすることができます。 VPN トンネルは接続の一方からだけ確立されるかもしれません。


IKEv1 のための RFC 参照

RFC4945 からのスニップはここにあります:

3.2.7.1. 認証局 (CA)の規定

キーイングマテリアルのインバンド交換を要求した場合、実装はローカル ポリシーが明示的にある特定の交換の間に信頼されて考える各ピア信頼固定用の CERTREQs を生成する必要があります。

RFC はクリアではないです。 暗号 ISAKMP プロファイルで設定されるローカル ポリシーはカリフォルニア信頼点のコマンドに明示的に関連するかもしれません。 問題はプロセスの MM3 および MM4 ステージにそれです、MM5 の認証およびプロセスの MM6 ステージが最初に行われる必要があるので識別および信頼ポイントのために IP アドレスを使用しなければ ISAKMP プロファイルを選択できません。 従って、ローカル ポリシーはデバイスで設定される信頼ポイントすべてに明示的に関連しています。


: この情報は Cisco 専用ではないですが、それは IKEv1-specific です。


オーバーラップする識別の IKEv2 プロファイル選択

IKEv2 のための多重 認証が記述されている前に、すべてのプロファイルのために満足する識別を一致する使用されるときプロファイルが選択される方法を知っていることは重要です。 これは IKEv2 ネゴシエーションの結果が複数のファクタによって決まるので推奨されるシナリオではないです。 同じ問題は IKEv1 のためにオーバーラップするプロファイルが使用されるときあります。

例 IKEv2 発信側 設定はここにあります:


crypto ikev2 proposal prop-1 
 encryption 3des
 integrity md5
 group 2
!
crypto ikev2 policy pol-1
 match fvrf any
 proposal prop-1
!
crypto ikev2 profile profile1
 match identity remote address 192.168.0.2 255.255.255.255
 identity local address 192.168.0.1
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1

crypto ipsec transform-set trans esp-3des esp-sha-hmac
 mode tunnel
!
crypto ipsec profile profile1
 set transform-set trans
 set ikev2-profile profile1
!
interface Loopback0
 ip address 192.168.100.1 255.255.255.255
!
interface Tunnel1
 ip address 10.0.0.1 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.2
 tunnel protection ipsec profile profile1
!
interface Ethernet0/0
 ip address 192.168.0.1 255.255.255.0

ip route 192.168.200.1 255.255.255.255 10.0.0.2

識別型アドレスは接続の両側のために使用されます。 認証による認証は(事前共有キーはまたある場合もあります)この例のために重要ではないです。 応答側に受信 IKEv2 トラフィック 一致する複数のプロファイルそのすべてあります:


crypto ikev2 proposal prop-1 
 encryption 3des
 integrity md5
 group 2
!
crypto ikev2 policy pol-1
 match fvrf any
 proposal prop-1
!
crypto ikev2 profile profile1
 match identity remote address 192.168.0.1 255.255.255.255
 identity local address 192.168.0.2
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1
!
crypto ikev2 profile profile2
 match identity remote address 192.168.0.1 255.255.255.255
 identity local address 192.168.0.2
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1
!
crypto ikev2 profile profile3
 match identity remote address 192.168.0.1 255.255.255.255
 identity local address 192.168.0.2
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1

crypto ipsec transform-set trans esp-3des esp-sha-hmac
 mode tunnel
!
crypto ipsec profile profile1
 set transform-set trans
 set ikev2-profile profile1
!
interface Loopback0
 ip address 192.168.200.1 255.255.255.255
!
interface Tunnel1
 ip address 10.0.0.2 255.255.255.0
 tunnel source Ethernet0/0
 tunnel destination 192.168.0.1
 tunnel protection ipsec profile profile1
!
interface Ethernet0/0
 ip address 192.168.0.2 255.255.255.0

ip route 192.168.100.1 255.255.255.255 10.0.0.1

発信側は第 3 IKEv2 パケットを送信 し、応答側は受け取られる識別に基づいてプロファイルを選択する必要があります。 識別は IPv4 アドレスです(192.168.0.1):


IKEv2:(SA ID = 1):Searching policy based on peer's identity '192.168.0.1' of
 type 'IPv4 address'

プロファイルすべては一致識別コマンドが理由で設定されるこの識別を満たします。 IOS はこの例の profile3 である設定の最後の 1 つを選択します、:


IKEv2:found matching IKEv2 profile 'profile3'

順序を確認するために、提示暗号 ikev2 profile コマンドを入力して下さい。


: 一般的 な アドレスがある時でさえ(0.0.0.0) プロファイルで、まだ選択されます。 IOS は最もよい一致を見つけるように試みません; それは最初の一致を見つけることを試みます。 ただし、これはプロファイルすべてに設定される同じマッチ識別 remote コマンドがあるのでだけ発生します。 異なる一致識別ルールがある IKEv2 プロファイルおよび IKEv1 に関しては、ほとんどの特定の 1 つは常に使用されます。 Cisco は選択されるプロファイルを予測することは困難であるのでオーバーラップ一致識別で設定されるプロファイルを持たないために命じることを推奨します。 


このシナリオでは、profile3 は応答側によって選択されますが、profile1 はトンネルインターフェイスのために使用されます。 プロキシ ID がネゴシエートされるときこれによりエラーは現われます:


*Jul 17 09:23:48.187: map_db_check_isakmp_profile profile did not match
*Jul 17 09:23:48.187: map_db_find_best did not find matching map
*Jul 17 09:23:48.187: IPSEC(ipsec_process_proposal):
 proxy identities not supported
*Jul 17 09:23:48.187: IKEv2:(SA ID = 1):There was no
 IPSEC policy found for received TS
*Jul 17 09:23:48.187: IKEv2:(SA ID = 1):
*Jul 17 09:23:48.187: IKEv2:(SA ID = 1):Sending TS unacceptable notify

IKEv2 は認証が使用されるときフローします

認証が IKEv2 のために認証するために使用されるとき発信側は最初のパケットの証明書要求 ペイロードを送信 しません:


IKEv2 IKE_SA_INIT Exchange REQUEST 
Payload contents:
 SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP)
 NOTIFY(NAT_DETECTION_DESTINATION_IP)

応答側がこの段階で使用する必要があるプロファイルを知らないので証明書要求 ペイロード(第 2 パケット)との応答側返事および CA すべて。 パケットは発信側に情報が含まれている送信 されます:


IKEv2 IKE_SA_INIT Exchange RESPONSE 
Payload contents:
 SA KE N VID VID NOTIFY(NAT_DETECTION_SOURCE_IP) NOTIFY
 (NAT_DETECTION_DESTINATION_IP) CERTREQ NOTIFY(HTTP_CERT_LOOKUP_SUPPORTED)

発信側はパケットを処理し、提案された CA と一致する信頼点を選択します:


IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s) from
 received certificate hash(es)
IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved trustpoint(s): 'TP1' 

発信側はそれから証明書要求および認証 ペイロード両方との第 3 パケットを送信 します。 このパケットは Diffie-Hellman (DH)フェーズからのキーイングマテリアルによって既に暗号化されています:


IKEv2:(SA ID = 1):Building packet for encryption.  
Payload contents:
 VID IDi CERT CERTREQ NOTIFY(HTTP_CERT_LOOKUP_SUPPORTED) AUTH CFG SA TSi
 TSr NOTIFY(INITIAL_CONTACT) NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT)
 NOTIFY(NON_FIRST_FRAGS)

第 4 パケットは応答側から発信側に送信 され、認証 ペイロードだけ含まれています:


IKEv2 IKE_AUTH Exchange RESPONSE 
Payload contents:
 VID IDr CERT AUTH SA TSi TSr NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT)
NOTIFY(NON_FIRST_FRAGS)

ここに記述されているフローは IKEv1 に類似したフローしますです。 応答側は使用する必要があるプロファイルの知識なしで証明書要求 ペイロードを前もって送信 する必要があります IKEv1 のために以前に記述されている同じ問題を引き起こす(プロトコル見通しから)。 ただし、IOS の実装は IKEv1 のより IKEv2 のためによいです。


発信側のための IKEv2 必須信頼点

IKEv2 発信側は証明書認証とプロファイルを使用するように試み、そのプロファイルの下で設定される信頼点があるとき例はのここにあります:


crypto ikev2 profile profile1
 match identity remote address 192.168.0.2 255.255.255.255
 identity local address 192.168.0.1
 authentication remote rsa-sig
 authentication local rsa-sig

最初のパケットは以前に記述されているように証明書要求 ペイロードなしで、送信 されます。 応答側からの応答はグローバル コンフィギュレーション モードで定義される信頼ポイントすべてのための証明書要求 ペイロードが含まれています。 これは発信側によって受け取られます:


*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s)
 from received certificate hash(es)

*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved
 trustpoint(s): 'TP1'   

*Jul 17 17:40:43.183: CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
*Jul 17 17:40:43.183: CRYPTO_PKI: Found a subject match
*Jul 17 17:40:43.183: CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
*Jul 17 17:40:43.183: CRYPTO_PKI: Found a subject match
*Jul 17 17:40:43.183: CRYPTO_PKI: Trust-Point TP1 picked up
*Jul 17 17:40:43.183: CRYPTO_PKI: 1 matching trustpoints found
*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s)
 from received certificate hash(es)

*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved
 trustpoint(s): 'TP2'   

*Jul 17 17:40:43.183: CRYPTO_PKI: Trust-Point TP2 picked up
*Jul 17 17:40:43.183: CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
*Jul 17 17:40:43.183: CRYPTO_PKI: Found a subject match
*Jul 17 17:40:43.183: CRYPTO_PKI: crypto_pki_get_cert_record_by_subject()
*Jul 17 17:40:43.183: CRYPTO_PKI: Found a subject match
*Jul 17 17:40:43.183: CRYPTO_PKI: 1 matching trustpoints found
*Jul 17 17:40:43.183: IKEv2:(SA ID = 1):Failed to build certificate payload

発信側は署名するために使用する必要がある信頼点を知りません。 これは IKEv2 実装が IKEv1 と比較されるとき主な違いです。 IKEv2 発信側は IKEv2 発信側 プロファイルの下で設定される信頼点がなければなりませんがそれは IKEv2 応答側に必要ではないです。

次にコマンド リファレンスからの抜粋を示します。

IKEv2 プロファイル設定で定義されるトラストポイントがない場合デフォルトはグローバルコンフィギュレーションで定義されるすべての trustpoints を使用して認証を検証することです

異なる信頼ポイントを定義することは可能性のあるです; 1 つ署名するためおよび別の 1 検証するため。 残念ながら、IKEv2 プロファイルの下で設定される必須信頼点は問題すべてを解決しません。


IKEv2 発信側として R2

この例では、R2 は IKEv2 発信側です:


crypto ikev2 profile profile1
 match identity remote address 192.168.0.1 255.255.255.255
 identity local address 192.168.0.2
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1
 pki trustpoint TP2

この例では、R1 は IKEv2 応答側です:


crypto ikev2 profile profile1
 match identity remote address 192.168.0.2 255.255.255.255
 identity local address 192.168.0.1
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint TP1

ここでは、R2 は証明書要求なしで最初のパケットを送信 します。 応答側は設定された信頼ポイントすべてのための証明書要求と応答します。 ペイロードの発注は IKEv1 に類似したで、インストールされている認証に依存しています:


R1#show crypto pki certificates 
Certificate
  Status: Available
  Certificate Serial Number (hex): 04
  Certificate Usage: General Purpose
  Issuer:
    cn=CA2
....
 Associated Trustpoints: TP2

R1 の最初の設定された認証は信頼点の TP2 と関連付けられます従って最初の証明書要求 ペイロードは信頼点の TP2 と関連付けられる CA のためです。 従って、R2 は認証(最初一致ルール)にそれを選択します:


R2#
*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):Processing IKE_SA_INIT message
*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s)
 from received certificate hash(es)
*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved
 trustpoint(s): 'TP2'   
*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Getting cert chain for
 the trustpoint TP2

*Jul 17 18:09:04.542: IKEv2:(SA ID = 1):[PKI -> IKEv2] Getting of cert chain
 for the trustpoint PASSED

それから、R2 は応答(TP2 と関連付けられる認証 要求 ペイロードとの 3) パケットを準備します。 R1 は信頼点の TP1 に対する検証のために設定されるので認証を信頼する場合がありません:


*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Retrieving trustpoint(s)
 from received certificate hash(es)
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[PKI -> IKEv2] Retrieved
 trustpoint(s): 'TP1'   

*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Getting cert chain for
 the trustpoint TP1
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[PKI -> IKEv2] Getting of cert chain
 for the trustpoint PASSED
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):Get peer's authentication method
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):Peer's authentication method is 'RSA'
*Jul 17 18:09:04.550: IKEv2:(SA ID = 1):[IKEv2 -> PKI] Validating
 certificate chain
*Jul 17 18:09:04.554: IKEv2:(SA ID = 1):[PKI -> IKEv2] Validation of certificate
 chain FAILED

*Jul 17 18:09:04.554: IKEv2:(SA ID = 1):Verification of peer's authentication
 data FAILED

*Jul 17 18:09:04.554: IKEv2:(SA ID = 1):Sending authentication failure notify
*Jul 17 18:09:04.554: IKEv2:(SA ID = 1):Building packet for encryption.  
Payload contents:
 NOTIFY(AUTHENTICATION_FAILED)

以前に述べられるように、Cisco は 1 IKEv2 プロファイル以下複数の信頼ポイントを使用しないことを推奨します。 複数の信頼ポイントを使用するとき、両側が同じ信頼ポイントを丁度信頼するようにすることは必要です。 たとえば、R1 におよび R2 に両方プロファイルで設定される TP1 および TP2 が両方あります。


要約

このセクションは資料に説明がある情報の短い要約を提供します。

証明書要求 ペイロード コンテンツは設定によって決まります。 特定の信頼点が ISAKMP プロファイルのために設定され、ルータが ISAKMP 発信側なら、MM3 の証明書要求は信頼点と関連付けられる CA だけ含まれています。 ただし同一ルータが ISAKMP 応答側なら、そして MM4 パケットはルータによって送信 される(カリフォルニア信頼点のコマンドが考慮に入れられないとき)グローバルに定義されした信頼ポイントすべてのための多重 認証 要求 ペイロードが含まれています。 これは ISAKMP 応答側が MM5 をおよび MM4 に含まれている証明書要求を受け取る後やっと使用する必要がある ISAKMP プロファイルを判別できるので発生します。

MM3 および MM4 の証明書要求 ペイロードは最初のマッチ ルールが理由で重要です。 最初の一致ルールは MM5 および MM6 の認証のために必要である証明書選択のために使用されること信頼点を判別します。

証明書要求 ペイロードの順序はインストールされている認証の発注によって決まります。 提示暗号 PKI certificate コマンドの出力に現われる最初の認証の発行元は最初に送信 されます。 この最初認証は登録される最後のものです。

ISAKMP プロファイルのための複数の信頼ポイントを設定することは可能性のあるです。 これが実行された場合、すべての前のルールはまだ適用されます。

この資料に説明がある警告および問題すべては IKEv1 プロトコル 設計が原因です。 認証段階は MM5 および MM6 に認証(証明書要求)のための提案は初期で使用する必要がある ISAKMP プロファイルの知識なしで(率直な)送信 する必要があるが、発生します。 これは Cisco 専用問題でし、IKEv1 プロトコル 設計の制限と関連しています。

IKEv2 プロトコルは認証 ネゴシエーションプロセスに関して IKEv1 に類似したです。 ただし、IOS の実装は発信側のための特定の信頼ポイントの使用を強制します。 これは問題すべてを解決しません。 複数の信頼ポイントが単一 プロファイルのために設定され、単一信頼点が反対側で設定されるとき、認証における問題に直面することはまだ可能性のあるです。 Cisco は接続(IKEv2 プロファイルの両方のために設定される同じ信頼ポイント)の両側のために対称信頼点のコンフィギュレーションを使用することを推奨します。

情報についてのいくつかの注記はここにありますこの資料に説明がある:

  • 同位の IKEv1 プロファイルのための非対称的な信頼点のコンフィギュレーションによって、トンネルはトンネルの一方だけから始まるかもしれません。 IKEv1 プロファイルのための信頼点の設定はオプションです。

  • 同位の IKEv2 プロファイルのための非対称的な信頼点のコンフィギュレーションによって、トンネルはトンネルの一方だけから始まるかもしれません。 IKEv2 プロファイルのための信頼点の設定は発信側のために必須です。

  • 証明書要求 ペイロード順序は提示暗号 PKI certificate コマンド(最初マッチ)の出力に現われる認証の発注によって決まります。

  • 証明書要求 ペイロード順序は応答側(最初マッチ)によって選択される認証を判別します。

  • IKEv1 および IKEv2 のために複数のプロファイルを使用し、同じ一致識別ルールを設定してもらうとき結果(含まれる余りにも多くのファクタ)を予測することは困難です。

  • Cisco は IKEv1 および IKEv2 両方のために対称信頼点のコンフィギュレーションを使用することを推奨します。

関連情報


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

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


Document ID: 117633