Sécurité et VPN : Protocole ISAKMP (Internet Security Association and Key Management Protocol)

Processus d'échange du paquet IKEv1 et IKEv2 IOS pour des profils avec de plusieurs Certificats

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit la version 1 (IKEv1) d'échange de clés Internet (IKE) et des processus d'échange de paquet de la version 2 d'échange de clés Internet (IKE) (IKEv2) quand l'authentification de certificat est utilisée et les problèmes éventuels qui pourraient se produire.

Voici une liste de sujets qui sont décrits dans ce document :

  • Les critères de sélection de certificat pour le demandeur d'Échange de clés Internet (IKE) et le responder d'IKE
  • Le critère de correspondance de profil d'IKE quand de plusieurs profils d'IKE sont appariés (pour des scénarios de superposition et de non-superposition)
  • Les valeurs par défaut et le comportement quand aucun confiance-point n'est utilisé sous les profils d'IKE
  • Les différences entre l'IKEv1 et l'IKEv2 en vue de des critères de sélection de profil et de certificat

Remarque: Pour des informations sur la façon dépanner un problème spécifique, référez-vous à la section correcte. En outre, un petit résumé est fourni à la fin de ce document.


Contribué par Michal Garcarz, ingénieur TAC Cisco.

Conditions préalables


Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Configuration du VPN de Cisco IOS®
  • Protocoles IKEv1 et IKEv2 (échange de paquet)

Composants utilisés

Les informations dans ce document sont basées sur le Cisco IOS Version15.3T.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.


Informations générales

Les problèmes qui sont décrits dans ce document surgissent quand de plusieurs confiance-points et plusieurs profils d'IKE sont utilisés.

Les exemples initiaux qui sont utilisés dans ce document ont un tunnel entre réseaux locaux IKEv1 avec deux confiance-points sur chaque routeur. Au début, il pourrait sembler que la configuration est correcte. Cependant, le tunnel VPN peut être initié seulement d'un côté de la connexion en raison de la manière dont la commande de ca trust-point est utilisé pour le comportement de profil de Protocole ISAKMP (Internet Security Association and Key Management Protocol) et pour la commande des Certificats inscrits dans la mémoire locale.

Un comportement différent est configuré avec la commande de ca trust-point pour le profil d'ISAKMP quand le routeur est le demandeur d'ISAKMP. Un problème pourrait se poser parce que le demandeur d'ISAKMP se rend compte du profil d'ISAKMP dès le début, ainsi la commande de ca trust-point qui est configurée pour le profil peut influencer la charge utile pour la demande de certificat en paquet principal 3 (MM3) de mode. Cependant, quand le routeur est le responder d'ISAKMP, il lie le trafic d'arrivée à un profil spécifique d'ISAKMP après qu'il reçoive le paquet principal 5 (MM5) de mode, qui inclut l'ID d'IKE qui est nécessaire afin de créer le grippage. C'est pourquoi il n'est pas possible de n'appliquer aucune commande de ca trust-point pour le paquet principal du paquet 4 de mode (MM4) parce que le profil n'est pas déterminé avant le MM5.

La commande du requestpayload de certificat dans le MM3 et le MM4 et de l'incidence sur le procédé entier de négociation est expliquée dans ce document, aussi bien que la raison pour laquelle elle permet seulement la connexion à établir d'un côté du tunnel VPN.

Voici un résumé des comportements du demandeur IKEv1 et du responder :


 Demandeur IKEv1Responder IKEv1
Envoyez la demandeEnvoie des demandes spécifiques seulement des confiance-points qui sont configurés sous le profil Envoie des demandes de tous les confiance-points disponibles
Validez la demandeValide contre les confiance-points spécifiques qui sont configurés sous le profilValide contre les confiance-points spécifiques qui sont configurés sous le profil


Cisco recommande que vous n'utilisiez pas la commande de ca trust-point pour les responders d'ISAKMP qui ont de plusieurs profils d'ISAKMP et utilisent les confiance-points global-configurés. Pour des demandeurs d'ISAKMP avec de plusieurs profils d'ISAKMP, Cisco recommande que vous rétrécissiez le processus de sélection de certificat avec la commande de ca trust-point dans chaque profil.

Le protocole IKEv2 a les mêmes questions que le protocole IKEv1, mais le comportement différent des aides de commande de point de confiance de PKI empêchent l'occurrence des problèmes. C'est parce que la commande de point de confiance de PKI est obligatoire pour le demandeur IKEv2, alors que la commande de ca trust-point est facultative pour le demandeur IKEv1. Dans certaines circonstances (plusieurs confiance-points au-dessous d'un profil), les problèmes précédemment décrits pourraient se poser. Pour cette raison, Cisco recommande que vous utilisiez des configurations confiance point symétriques pour les deux côtés de la connexion (les mêmes confiance-points configurés sous chacun des deux profils IKEv2).


Topologie

C'est une topologie générique qui est utilisée pour tous les exemples dans ce document.


Remarque: Interfaces de tunnel virtuelles d'utilisation du routeur 1 (R1) et du Router2 (R2) (VTIs) afin d'accéder aux bouclages. Ces VTIs sont protégés par IPSec.


Pour cet exemple IKEv1, chaque routeur a deux confiance-points pour chaque Autorité de certification (CA), et les Certificats pour chacun des confiance-points sont inscrits.

Quand R1 est le demandeur d'ISAKMP, le tunnel négocie correctement et le trafic est protégé. C'est comportement prévu. Quand R2 est le demandeur d'ISAKMP, la négociation Phase1 échoue.


Remarque: Pour les exemples IKEv2 dans ce document, la topologie et l'adressage est identique que qui affiché l'exemple IKEv1.


Processus d'échange de paquet

Cette section décrit les IKEv1 et les variations de la configuration IKEv2 qui sont utilisés pour le processus d'échange de paquet, et les problèmes éventuels qui pourraient surgir.


IKEv1 avec de plusieurs Certificats

Voici le réseau R1 et la configuration du VPN pour IKEv1 avec de plusieurs Certificats :


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

Voici le réseau R2 et la configuration du VPN pour IKEv1 avec de plusieurs Certificats :


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

Dans cet exemple, R1 a deux confiance-points : on utilise IOSCA1 et les deuxièmes utilisations 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

Dans cet exemple, R2 a également deux confiance-points : on utilise IOSCA1 et les deuxièmes utilisations 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

Il est important de noter la différence simple dans ces configurations : le profil de l'ISAKMP R1 utilise la commande de ca trust-point pour l'IOSCA1 confiance point, qui indique que R1 fait confiance seulement aux Certificats qui sont validés par cette particularité confiance point. En revanche, R2 fait confiance à tous les Certificats qui sont validés par tous les confiance-points global-définis.


R1 comme demandeur IKEv1

Voici met au point des commandes pour R1 et R2 :

  • Debug crypto isakmp R1#
  • Debug crypto ipsec R1#
  • Validation de PKI de debug crypto R1#

Ici, R1 initie le tunnel et envoie au requestin de certificat le 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

Il est important de noter que le paquet contient seulement une demande de certificat, qui est seulement pour l'IOSCA1 confiance point. C'est comportement prévu avec la configuration en cours du profil d'ISAKMP (CN=CA1, O=cisco, O=com). Aucune autre demande de certificat n'est envoyée, que vous pouvez vérifier avec la configuration incluse de capture de paquet :



Quand R2 reçoit le paquet, il commence à traiter la demande de certificat, qui crée une correspondance qui détermine le confiance point et le certificat associé qui est utilisé pour l'authentification dans le MM5. La commande de processus est identique comme la charge utile de demande de certificat dans le paquet d'ISAKMP. Ceci signifie que la première correspondance est utilisée. Dans ce scénario, il y a seulement une correspondance puisque R1 est configuré avec du confiance point spécifique et envoie seulement une demande de certificat qui est associée avec du confiance point.


*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

Après, R2 prépare le MM4. C'est le paquet qui contient la demande de certificat de tous les confiance-points de confiance. Puisque R2 est le responder d'ISAKMP, tous les confiance-points global-définis sont de confiance (la configuration de ca trust-point n'est pas vérifiée). Deux des confiance-points sont définis manuellement (IOSCA1 et IOSCA2), et le repos sont des prédéfinis.


*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

Vous pouvez vérifier le paquet avec Wireshark. Le paquet MM4 de R2 contient sept entrées de demande de certificat :



Puis, R1 reçoit le MM4 de R2 avec des champs de demande de plusieurs certificat :


*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

La règle de premier-correspondance sur R1 apparie la première demande de certificat avec l'IOSCA1 confiance point. Ceci détermine que R1 utilise le certificat qui est associé avec IOSCA1 confiance point pour l'authentification dans le MM5. Le nom de domaine complet (FQDN) est utilisé comme ID d'IKE. C'est dû à la configuration FQDN de self-identity dans le profil d'ISAKMP :


*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

Le MM5 est reçu et traité par R2. L'ID d'IKE reçu (R1.cisco.com) apparie le profil prof1 d'ISAKMP. Le certificat reçu est alors validé et l'authentification est réussie :


*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

Puis, R2 prépare le MM6 avec le certificat qui est associé avec IOSCA1 :


*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

Le paquet est reçu par R1, et R1 vérifie le certificat et l'authentification :


*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

Ceci finit la phase où 1. Phase 2 est négocié comme d'habitude. Le tunnel est établi avec succès et le trafic est protégé.


R2 comme demandeur IKEv1

Cet exemple décrit le processus quand R2 initie le même tunnel IKEv1 et explique pourquoi on ne l'établit pas.


Remarque: Des parties des logs sont retirées afin de se concentrer seulement sur les différences par rapport à l'exemple présenté dans la section précédente.


R2 envoie le MM3 avec sept charges utiles de demande de certificat parce que R2 n'a pas un associé confiance point au profil d'ISAKMP (tous les confiance-points sont de confiance) :


*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

Quand R1 reçoit le paquet de R2, il traite la demande de certificat et apparie l'IOSCA1 confiance point, qui détermine le certificat qui est introduit le MM6 :


*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

Après, R1 prépare le paquet MM4 avec la charge utile de demande de certificat. Maintenant il y a des charges utiles de demande de plusieurs certificat :


*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

Vérifiez les logs avec la capture incluse de paquet (CPE) et le Wireshark :



Quoique R1 soit configuré pour un confiance point simple (IOSCA1) dans le profil d'ISAKMP, il y a des demandes de plusieurs certificat envoyées. Ceci se produit parce que la commande de ca trust-point dans le profil d'ISAKMP détermine la charge utile de demande de certificat, mais seulement quand le routeur est le demandeur de la session d'ISAKMP. Si le routeur est le responder, il y a des charges utiles de demande de plusieurs certificat pour tous les confiance-points global-définis parce que R1 ne connaît pas encore le profil d'ISAKMP qui est utilisé pour la session d'IKE.

La session d'arrivée d'IKE est liée à un profil spécifique d'ISAKMP après la réception du MM5, qui inclut l'identification d'IKE après, la commande de match identity pour le profil spécifique lie la session d'IKE au profil. Cependant, le routeur ne peut pas déterminer ceci jusqu'ici. Il pourrait y avoir de plusieurs profils d'ISAKMP avec différentes commandes de ca trust-point configurées pour chaque profil.

Pour cette raison, R1 doit envoyer la demande de certificat de tous les confiance-points global-configurés.

Référez-vous à la référence de commandes pour la commande de ca trust-point :

Un routeur initiant l'IKE et un routeur répondant à la demande d'IKE devraient avoir des configurations symétriques de point de confiance. Par exemple, un routeur répondant (en mode principal d'IKE) exécutant le cryptage et l'authentification de signature RSA pourrait utiliser les points de confiance qui ont été définis en configuration globale en envoyant les charges utiles CERT-REQ. Cependant, le routeur pourrait utiliser une liste restreinte de points de confiance qui ont été définis dans le profil d'ISAKMP pour la vérification de certificat. Si le pair (le demandeur d'IKE) est configuré pour utiliser un certificat dont le point de confiance est dans la liste globale du routeur répondant mais pas dans le profil d'ISAKMP du routeur répondant, le certificat est rejeté. (Cependant, si le routeur initiant ne sait pas les points de confiance en configuration globale du routeur répondant, le certificat peut encore être authentifié.)

Vérifiez maintenant les détails du paquet MM4 afin de découvrir la première charge utile de demande de certificat :



Le paquet MM4 qui est envoyé de R1 inclut l'IOSCA2 confiance point dans la première charge utile de demande de certificat en raison de la commande dans laquelle les Certificats sont installés ; le premier est signé par l'IOSCA2 confiance point :


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>

Faites une comparaison avec le paquet MM3 qui est envoyé de R2 quand l'IOSCA1 confiance point est inclus dans la première charge utile de demande de certificat :


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>

Maintenant R2 reçoit le paquet MM4 de R1 et commence à traiter la demande de certificat. La première charge utile de demande de certificat apparie l'IOSCA2 confiance point :


*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

Quand R2 prépare le paquet MM5, il utilise le certificat qui est associé avec l'IOSCA2 confiance point :


*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.

Le paquet MM5 est reçu par R1. Puisque R1 fait confiance seulement à l'IOSCA1 confiance point (pour profil prof1 d'ISAKMP), la validation de certificat échoue :


*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

Cette configuration fonctionne si la commande de l'inscription de certificat sur R1 est différente parce que le certificat d'abord affiché est signé par l'IOSCA1 confiance point. En outre, la première charge utile de demande de certificat dans le MM4 est l'IOSCA1 confiance point, qui est alors choisi par R2 et avec succès validé sur R1 dans le MM6.


IKEv1 sans commande de ca trust-point dans le profil

Pour des scénarios avec de plusieurs profils et confiance-points mais sans configuration confiance point spécifique dans les profils, il n'y a aucune question parce qu'il n'y a aucune validation des confiance-points spécifiques déterminés par une configuration de commande de ca trust-point. Cependant, le processus de sélection ne pourrait pas être évident. La personne à charge sur le routeur qui est le demandeur, les différents Certificats sont sélectionnées pour la procédure d'authentification par rapport à la commande de l'inscription de certificat.

Parfois un certificat peut être pris en charge par seulement un côté de la connexion, comme dans la version 1 x509, qui n'est pas une fonction d'informations parasites typique qui est utilisée afin de signer. Le tunnel VPN pourrait être établi seulement d'un côté de la connexion.


Référence RFC pour IKEv1

Voici un bout de RFC4945 :

3.2.7.1. Spécifier des autorités de certification

En demandant l'échange d'intrabande des matériels de base, les réalisations DEVRAIENT générer CERTREQs pour chaque ancre de confiance de pair laquelle la stratégie locale considère explicitement faite confiance pendant un échange donné.

Le RFC n'est pas clair. La stratégie locale explicitement pourrait associer à la commande de ca trust-point qui est configurée dans le crypto isakmp profile. Le problème est celui à l'étape MM3 et MM4 du processus, vous ne pouvez pas sélectionner un profil d'ISAKMP à moins que vous utilisiez une adresse IP pour l'identité et les confiance-points parce que l'authentification dans le MM5 et l'étape MM6 du processus doivent se produire d'abord. Pour cette raison, la stratégie locale associe explicitement à tous les confiance-points qui sont configurés sur le périphérique.


Remarque: Ces informations ne sont pas Cisco-particularité, mais c'est IKEv1-specific.


Sélection du profil IKEv2 avec les identités qui superposent

Avant que de plusieurs Certificats pour IKEv2 soient décrits, il est important de connaître la manière dont les profils sont sélectionné quand le match identity est utilisé, qui est satisfait pour tous les profils. Ce n'est pas un scénario recommandé parce que les résultats de la négociation IKEv2 dépend de plusieurs facteurs. Les mêmes problèmes existent pour IKEv1 quand des profils qui superposent sont utilisés.

Voici une configuration de demandeur de l'exemple 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

L'adresse de type d'identité est utilisée pour les deux côtés de la connexion. L'authentification par l'intermédiaire des Certificats (peuvent également être les clés pré-partagées) n'est pas importante pour cet exemple. Le responder a les plusieurs profils que tout apparie le trafic IKEv2 d'arrivée :


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

Le demandeur envoie le troisième paquet IKEv2, et le responder doit choisir le profil basé sur l'identité qui est reçue. L'identité est un ipv4 addres (192.168.0.1) :


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

Tous les profils satisfont cette identité en raison de la commande de match identity qui est configurée. L'IOS choisit dernier dans la configuration, qui est profile3 dans cet exemple :


IKEv2:found matching IKEv2 profile 'profile3'

Afin de vérifier la commande, sélectionnez la crypto commande du profil ikev2 d'exposition.


Remarque: Même lorsqu'il y a une adresse générique (0.0.0.0) dans le profil, il est encore sélectionné. L'IOS ne tente pas de trouver une meilleure correspondance ; il essaye de trouver la première correspondance. Cependant, ceci se produit seulement parce que tous les profils ont la même remote command de match identity configurée. Pour les IKEv1 et les profils IKEv2 qui ont différentes règles de match identity, les la plupart spécifiques sont toujours utilisées. Cisco recommande que vous ne pas avoir les profils configurés avec le match identity superposant commandiez parce qu'il est difficile de prévoir le profil qui est sélectionné. 


Dans ce scénario, profile3 est sélectionné par le responder, mais profile1 est utilisé pour l'interface de tunnel. Ceci fait apparaître une erreur quand l'ID de proxy est négocié :


*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 circulent quand des Certificats sont utilisés

Quand des Certificats sont utilisés pour IKEv2 afin d'authentifier, le demandeur n'envoie pas la charge utile de demande de certificat dans le premier paquet :


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

Les réponses de responder avec le certificat demandent la charge utile (deuxième paquet) et tout les CAs parce que le responder n'a aucune connaissance du profil qui devrait être utilisé à ce stade. Le paquet qui contient les informations est envoyé au demandeur :


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)

Le demandeur traite le paquet et choisit un confiance point qui apparie le CA proposé :


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

Le demandeur envoie alors au troisième paquet avec chacun des deux la demande de certificat et la charge utile de certificat. Ce paquet est déjà chiffré avec le matériel de base de la phase de Protocole DH (Diffie-Hellman) :


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)

Le quatrième paquet est envoyé du responder au demandeur et contient seulement la charge utile de certificat :


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)

L'écoulement décrit ici est semblable à l'IKEv1 circulent. Le responder doit envoyer la charge utile de demande de certificat d'avance sans connaissance du profil qui devrait être utilisé, qui crée les mêmes problèmes qui sont précédemment décrits pour IKEv1 (d'un point de vue de protocole). Cependant, l'implémentation sur l'IOS est meilleure pour l'IKEv2 que pour l'IKEv1.


Confiance point IKEv2 obligatoire pour le demandeur

Voici un exemple de quand les tentatives d'un demandeur IKEv2 d'utiliser un profil avec l'authentification de certificat et n'a pas confiance point configuré sous ce profil :


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

Le premier paquet est envoyé sans n'importe quelle charge utile de demande de certificat, comme décrit précédemment. La réponse du responder inclut la charge utile de demande de certificat pour tous les confiance-points qui sont définis en mode de configuration globale. Ceci est reçu par le demandeur :


*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

Le demandeur ne connaît pas le confiance point qui devrait être utilisé afin de signer. C'est la principale différence quand l'implémentation IKEv2 est comparée à l'IKEv1. Le demandeur IKEv2 doit avoir le confiance point configuré sous le profil du demandeur IKEv2, mais il n'est pas nécessaire pour le responder IKEv2.

Voici un extrait de la référence de commandes :

S'il n'y a aucun point de confiance défini dans la configuration du profil IKEv2, le par défaut est de valider le certificat utilisant tous les points de confiance qui sont définis en configuration globale

Il est possible de définir différents confiance-points ; un afin de signer et différent afin de valider. Malheureusement, le confiance point obligatoire qui est configuré sous le profil IKEv2 ne résout pas tous les problèmes.


R2 comme demandeur IKEv2

Dans cet exemple, R2 est le demandeur 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

Dans cet exemple, R1 est le responder 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

Ici, R2 envoie le premier paquet sans n'importe quelle demande de certificat. Le responder répond avec une demande de certificat de tous les confiance-points configurés. La commande des charges utiles est semblable à l'IKEv1 et dépend des Certificats qui sont installés :


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

Le certificat d'abord configuré sur R1 est associé avec le TP2 confiance point, ainsi la première charge utile de demande de certificat est pour le CA qui est associé avec le TP2 confiance point. Ainsi, R2 le sélectionne pour l'authentification (première règle de correspondance) :


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

Puis, R2 prépare une réponse (paquet 3) avec la charge utile de demande de certification qui est associée avec TP2. R1 ne peut pas faire confiance au certificat puisqu'il est configuré pour la validation contre le TP1 confiance point :


*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)

Comme précédemment mentionné, Cisco recommande que vous n'utilisiez pas de plusieurs confiance-points au-dessous d'un profil IKEv2. Quand vous utilisez de plusieurs confiance-points, il est nécessaire d'assurer ce les deux côtés confiance exactement les mêmes confiance-points. Par exemple, R1 et R2 ont TP1 et TP2 configurés dans leurs profils.


Résumé

Cette section fournit un résumé rapide des informations qui sont décrites dans le document.

Le contenu de charge utile de demande de certificat dépend de la configuration. Si un confiance point spécifique est configuré pour le profil d'ISAKMP et le routeur est le demandeur d'ISAKMP, alors la demande de certificat dans le MM3 contient seulement le CA qui est associé avec du confiance point. Cependant, si le même routeur est le responder d'ISAKMP, puis le paquet MM4 qui est envoyé par le routeur inclut des charges utiles de demande de plusieurs certificat pour tous les confiance-points global-définis (quand la commande de ca trust-point n'est pas prise en compte). Ceci se produit parce que le responder d'ISAKMP peut déterminer le profil d'ISAKMP qui devrait être utilisé seulement après qu'il reçoit le MM5 et la demande de certificat qui est incluse dans le MM4.

La charge utile de demande de certificat dans le MM3 et le MM4 est importante en raison de la première règle de correspondance. La première règle de correspondance détermine le confiance point qu'est utilisé pour la sélection de certificat, qui est nécessaire pour l'authentification dans le MM5 et le MM6.

La commande de la charge utile de demande de certificat dépend sur l'ordre des Certificats qui sont installés. L'émetteur du premier certificat qui apparaît dans la sortie de la crypto commande de certificat de PKI d'exposition est envoyé d'abord. Ce premier certificat est dernier qui est inscrit.

Il est possible de configurer de plusieurs confiance-points pour un profil d'ISAKMP. Si ceci est exécuté, alors toutes les règles précédentes s'appliquent toujours.

Tous les problèmes et mises en garde qui sont décrits dans ce document sont dus à la conception du protocole IKEv1. L'étape d'authentification se produit dans le MM5 et le MM6, alors que les propositions pour l'authentification (demandes de certificat) doivent être envoyées à une partie (franche) sans connaissance du profil d'ISAKMP qui devrait être utilisé. Ce n'est pas un problème de Cisco-particularité et est lié aux limites de la conception du protocole IKEv1.

Le protocole IKEv2 est semblable à l'IKEv1 en vue de le procédé de négociation de certificat. Cependant, l'implémentation sur l'IOS force l'utilisation des confiance-points spécifiques pour le demandeur. Ceci ne résout pas tous les problèmes. Quand de plusieurs confiance-points sont configurés pour un profil simple et un confiance point simple est configuré de l'autre côté, il est encore possible de rencontrer des problèmes avec l'authentification. Cisco recommande que vous utilisiez des configurations confiance point symétriques pour les deux côtés de la connexion (les mêmes confiance-points configurés pour chacun des deux profils IKEv2).

Voici quelques informations importantes au sujet des informations qui sont décrites dans ce document :

  • Avec des configurations confiance point asymétriques pour les profils IKEv1 des pairs, le tunnel pourrait initier de seulement un côté du tunnel. La configuration confiance point pour le profil IKEv1 est facultative.

  • Avec des configurations confiance point asymétriques pour les profils IKEv2 des pairs, le tunnel pourrait initier de seulement un côté du tunnel. La configuration confiance point pour le profil IKEv2 est obligatoire pour le demandeur.

  • La commande de charge utile de demande de certificat dépend sur l'ordre des Certificats qui apparaissent dans la sortie de la crypto commande de certificat de PKI d'exposition (première correspondance).

  • La commande de charge utile de demande de certificat détermine le certificat qui est sélectionné par le responder (première correspondance).

  • Quand vous utilisez de plusieurs profils pour l'IKEv1 et l'IKEv2 et faites configurer les mêmes règles de match identity, il est difficile de prévoir les résultats (trop de facteurs impliqués).

  • Cisco recommande que vous utilisiez des configurations confiance point symétriques pour l'IKEv1 et l'IKEv2.

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 117633