Seguridad y VPN : Protocolo de administración de claves y asociaciones de seguridad de Internet (ISAKMP)

Procesos del intercambio de paquetes IKEv1 e IKEv2 IOS para los perfiles con los certificados múltiples

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe los procesos del intercambio de claves de Internet del intercambio de paquetes de la versión 1 (IKEv1) y del intercambio de claves de Internet versión 2 (IKEv2) cuando se utiliza la autenticación certificada y los Posibles problemas que pudieron ocurrir.

Aquí está una lista de temas que se describan en este documento:

  • El Criterio de selección del certificado para el iniciador del Internet Key Exchange (IKE) y el respondedor IKE
  • Los criterios de concordancia del perfil IKE cuando se corresponden con los perfiles múltiples IKE (para los escenarios de la coincidencia y de la NON-coincidencia)
  • Las configuraciones predeterminadas y el comportamiento cuando no se utiliza ningunas confianza-puntas bajo perfiles IKE
  • Las diferencias entre el IKEv1 y el IKEv2 con respecto al Criterio de selección del perfil y del certificado

Nota: Para más información sobre cómo resolver problemas un problema específico, refiera a la sección correcta. También, un resumen corto se proporciona en el extremo de este documento.


Contribuido por Michal Garcarz, ingeniero de Cisco TAC.

Prerrequisitos


Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

  • Configuración VPN del ® del Cisco IOS
  • Protocolos IKEv1 e IKEv2 (intercambio de paquetes)

Componentes Utilizados

La información en este documento se basa en el Cisco IOS Version15.3T.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.


Antecedentes

Los problemas que se describen en este documento se presentan cuando se utilizan las confianza-puntas múltiples y los perfiles múltiples IKE.

Los ejemplos iniciales que se utilizan en este documento tienen un túnel de LAN a LAN IKEv1 con dos confianza-puntas en cada router. Al principio, puede ser que parezca que la configuración está correcta. Sin embargo, el túnel VPN se puede iniciar solamente a partir de un lado de la conexión debido a la manera que el comando de la confianza-punta Ca se utiliza para el comportamiento del perfil del Internet Security Association and Key Management Protocol (ISAKMP) y para la pedido de los Certificados alistados en el almacén local.

Un diverso comportamiento se configura con el comando de la confianza-punta Ca para el perfil ISAKMP cuando el router es el iniciador ISAKMP. Un problema pudo ocurrir porque el iniciador ISAKMP es consciente del perfil ISAKMP desde el principio, tan el comando de la confianza-punta Ca que se configura para el perfil puede influenciar el payload para el pedido de certificado en el paquete 3 (MM3) del modo principal. Sin embargo, cuando el router es el respondedor ISAKMP, ata el tráfico entrante a un perfil específico ISAKMP después de que reciba el paquete 5 (MM5) del modo principal, que incluye el IKE ID que es necesario para crear el lazo. Esta es la razón por la cual no es posible aplicar ningún comando de la confianza-punta Ca para el paquete del paquete 4 del modo principal (MM4) porque el perfil no se determina antes del MM5.

La orden del requestpayload del certificado en el MM3 y el MM4 y del proceso de negociación del impacto en general se explica en este documento, así como la razón que permite solamente que la conexión sea establecida a partir de un lado del túnel VPN.

Aquí está un resumen de los comportamientos del iniciador IKEv1 y del respondedor:


 Iniciador IKEv1Respondedor IKEv1
Envíe la peticiónEnvía las peticiones específicas solamente para las confianza-puntas que se configuran bajo perfil Envía los pedidos todas las confianza-puntas disponibles
Valide la peticiónValida contra las confianza-puntas específicas que se configuran bajo perfilValida contra las confianza-puntas específicas que se configuran bajo perfil


Cisco recomienda que usted no utiliza el comando de la confianza-punta Ca para los respondedores ISAKMP que tienen perfiles múltiples ISAKMP y utilizan las confianza-puntas global-configuradas. Para los iniciadores ISAKMP con los perfiles múltiples ISAKMP, Cisco recomienda que usted estrecha el proceso de selección del certificado con el comando de la confianza-punta Ca en cada perfil.

El protocolo IKEv2 tiene los mismos problemas que el protocolo IKEv1, pero el diverso comportamiento de las ayudas del comando del trustpoint del pki previene el acontecimiento de los problemas. Esto es porque el comando del trustpoint del pki es obligatorio para el iniciador IKEv2, mientras que el comando de la confianza-punta Ca es opcional para el iniciador IKEv1. En algunas circunstancias (confianza-puntas múltiples bajo un perfil), los problemas previamente descritos pudieron ocurrir. Por este motivo, Cisco recomienda que usted utiliza las configuraciones simétricas de la confianza-punta para los ambos lados de la conexión (las mismas confianza-puntas configuradas bajo ambos perfiles IKEv2).


Topología

Ésta es una topología genérica que se utiliza para todos los ejemplos en este documento.


Nota: Interfaces del túnel virtuales del uso del router1 (r1) y del router2 (r2) (VTIs) para acceder los loopback. Este VTIs es protegido por el IPSec.


Por este ejemplo IKEv1, cada router tiene dos confianza-puntas para cada Certificate Authority (CA), y los Certificados para cada uno de las confianza-puntas se alistan.

Cuando el r1 es el iniciador ISAKMP, el túnel negocia correctamente y se protege el tráfico. Debe ocurrir lo siguiente. Cuando el r2 es el iniciador ISAKMP, la negociación Phase1 falla.


Nota: Por los ejemplos IKEv2 en este documento, la topología y la dirección es lo mismo que mostrado el ejemplo IKEv1.


Proceso del intercambio de paquetes

Esta sección describe los IKEv1 y las Variaciones de la configuración IKEv2 que se utilizan para el proceso del intercambio de paquetes, y los Posibles problemas que pudieron presentarse.


IKEv1 con los certificados múltiples

Aquí está la red y la configuración VPN del r1 para IKEv1 con los certificados múltiples:


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

Aquí está la red y la configuración VPN del r2 para IKEv1 con los certificados múltiples:


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

En este ejemplo, el r1 tiene dos confianza-puntas: uno utiliza IOSCA1 y las segundas aplicaciones 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

En este ejemplo, el r2 también tiene dos confianza-puntas: uno utiliza IOSCA1 y las segundas aplicaciones 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

Es importante observar la sola diferencia en estas configuraciones: el perfil del r1 ISAKMP utiliza el comando de la confianza-punta Ca para la confianza-punta IOSCA1, que indica que el r1 confía en solamente los Certificados que son validados por esa confianza-punta específica. En cambio, el r2 confía en todos los Certificados que sean validados por todas las confianza-puntas global-definidas.


R1 como el iniciador IKEv1

Aquí están los comandos debugs para el r1 y el r2:

  • Isakmp del debug crypto R1#
  • IPSec del debug crypto R1#
  • Validación del pki del debug crypto R1#

Aquí, el r1 inicia el túnel y envía el requestin del certificado el 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

Es importante notar que el paquete contiene solamente un pedido de certificado, que está solamente para la confianza-punta IOSCA1. Ésta es conducta esperada con la configuración actual del perfil ISAKMP (CN=CA1, O=cisco, O=com). No se envía ningunos otros pedidos de certificado, que usted puede verificar con la característica integrada de la captura de paquetes:



Cuando el r2 recibe el paquete, comienza a procesar el pedido de certificado, que crea un emparejamiento que determine la confianza-punta y el certificado asociado que se utiliza para la autenticación en el MM5. La orden de proceso es lo mismo que el payload del pedido de certificado en el paquete ISAKMP. Esto significa que la primera coincidencia está utilizada. En este escenario, hay solamente una coincidencia puesto que el r1 se configura con una confianza-punta específica y envía solamente un pedido de certificado que se asocie a la confianza-punta.


*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

Luego, el r2 prepara el MM4. Éste es el paquete que contiene el pedido de certificado para todas las confianza-puntas de confianza. Puesto que el r2 es el respondedor ISAKMP, se confían en todas las confianza-puntas global-definidas (la configuración de la confianza-punta Ca no se marca). Dos de las confianza-puntas se definen manualmente (IOSCA1 e IOSCA2), y se predefine el resto.


*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

Usted puede verificar el paquete con Wireshark. El paquete MM4 del r2 contiene siete entradas del pedido de certificado:



Entonces, el r1 recibe el MM4 del r2 con los campos de la petición del certificado múltiple:


*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 regla de la primero-coincidencia en el r1 hace juego el primer pedido de certificado con la confianza-punta IOSCA1. Esto determina que el r1 utiliza el certificado que se asocia a la confianza-punta IOSCA1 para la autenticación en el MM5. El nombre de dominio completo (FQDN) se utiliza como el IKE ID. Esto es debido a la configuración FQDN de la uno mismo-identidad en el perfil 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

El MM5 es recibido y procesado por el r2. El IKE recibido ID (R1.cisco.com) hace juego el perfil prof1 ISAKMP. El certificado recibido entonces se valida y la autenticación es acertada:


*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

Entonces, el r2 prepara el MM6 con el certificado que se asocia a 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

El paquete es recibido por el r1, y el r1 verifica el certificado y la autenticación:


*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

Esto completa la fase que 1. fases 2 se negocian como de costumbre. El túnel se establece con éxito y se protege el tráfico.


R2 como el iniciador IKEv1

Este ejemplo describe el proceso cuando el r2 inicia el mismo túnel IKEv1 y explica porqué no se establece.


Nota: Las porciones de los registros se quitan para centrarse solamente en las diferencias en relación con el ejemplo presentado en la sección anterior.


El r2 envía el MM3 con siete cargas útiles del pedido de certificado porque el r2 no tiene una confianza-punta asociada al perfil ISAKMP (se confían en todas las confianza-puntas):


*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

Cuando el r1 recibe el paquete del r2, procesa el pedido de certificado y corresponde con la confianza-punta IOSCA1, que determina el certificado que se envía en el 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

Luego, el r1 prepara el paquete MM4 con el payload del pedido de certificado. Ahora hay cargas útiles de la petición del certificado múltiple:


*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

Verifique los registros con la captura de paquetes integrada (EPC) y Wireshark:



Aunque el r1 se configura para una sola confianza-punta (IOSCA1) en el perfil ISAKMP, hay peticiones del certificado múltiple enviadas. Esto ocurre porque el comando de la confianza-punta Ca en el perfil ISAKMP determina el payload del pedido de certificado, pero solamente cuando el router es el iniciador de la sesión ISAKMP. Si el router es el respondedor, hay cargas útiles de la petición del certificado múltiple para todas las confianza-puntas global-definidas porque el r1 todavía no conoce el perfil ISAKMP que se utiliza para la sesión IKE.

La sesión IKE entrante está limitada a un perfil específico ISAKMP después de la recepción del MM5, que incluye la identificación IKE luego, el comando de la identidad de la coincidencia para el perfil específico ata a la sesión IKE al perfil. Sin embargo, el router no puede determinar esto hasta ahora. Pudo haber perfiles múltiples ISAKMP con diversos comandos de la confianza-punta Ca configurados para cada perfil.

Por este motivo, el r1 debe enviar el pedido de certificado para todas las confianza-puntas global-configuradas.

Refiera a la referencia de comandos para el comando de la confianza-punta Ca:

Un router que inicia el IKE y un router que responde a la petición IKE deben tener configuraciones simétricas del trustpoint. Por ejemplo, un router de respuesta (en el modo principal IKE) que realizaba el cifrado y la autenticación de la firma RSA. pudo utilizar el trustpoints que fue definido en la configuración global al enviar las cargas útiles CERT REQ. Sin embargo, el router pudo utilizar una lista restricta de trustpoints que fue definido en el perfil ISAKMP para la verificación del certificado. Si configuran al par (el iniciador IKE) para utilizar un certificado cuyo trustpoint esté en la lista global del router de respuesta pero no en el perfil ISAKMP del router de respuesta, se rechaza el certificado. (Sin embargo, si el router de iniciación no sabe sobre el trustpoints en la configuración global del router de respuesta, el certificado se puede todavía autenticar.)

Ahora verifique los detalles del paquete MM4 para descubrir el primer payload del pedido de certificado:



El paquete MM4 que se envía del r1 incluye la confianza-punta IOSCA2 en el primer payload del pedido de certificado debido a la orden en la cual los Certificados están instalados; primer es firmado por la confianza-punta 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>

Haga una comparación con el paquete MM3 que se envía del r2 cuando la confianza-punta IOSCA1 se incluye en el primer payload del pedido de certificado:


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>

Ahora el r2 recibe el paquete MM4 del r1 y comienza a procesar el pedido de certificado. El primer payload del pedido de certificado hace juego la confianza-punta 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

Cuando el r2 prepara el paquete MM5, utiliza el certificado que se asocia a la confianza-punta 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.

El paquete MM5 es recibido por el r1. Porque el r1 confía en solamente la confianza-punta IOSCA1 (para el perfil prof1 ISAKMP), la validación de certificado falla:


*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

Esta configuración trabaja si la orden de la inscripción del certificado en el r1 es diferente porque el primer certificado visualizado es firmado por la confianza-punta IOSCA1. También, el primer payload del pedido de certificado en el MM4 es la confianza-punta IOSCA1, que después es elegida por el r2 y validada con éxito en el r1 en el MM6.


IKEv1 sin un comando de la confianza-punta Ca en el perfil

Para los escenarios con los perfiles y las confianza-puntas múltiples pero sin una configuración específica de la confianza-punta en los perfiles, no hay problemas porque no hay validación de las confianza-puntas específicas determinadas por un comando configuration de la confianza-punta Ca. Sin embargo, el proceso de selección no pudo ser obvio. Seleccionan al dependiente sobre el router que es el iniciador, los diversos Certificados para el proceso de autenticación en relación con la orden de la inscripción del certificado.

Un certificado se puede soportar a veces por solamente un lado de la conexión, por ejemplo en la versión 1 x509, que no es una función de troceo típica que se utiliza para firmar. El túnel VPN se pudo establecer solamente a partir de un lado de la conexión.


Referencia RFC para IKEv1

Aquí está un recorte del RFC4945:

3.2.7.1. Especificar las autoridades de certificación

Al pedir el intercambio de la en-banda de los materiales de codificación, las implementaciones DEBEN generar CERTREQs para cada ancla de la confianza del par que la política local juzgue explícitamente de confianza durante un intercambio dado.

El RFC no está claro. La política local pudo relacionarse explícitamente con el comando de la confianza-punta Ca que se configura en el perfil crypto ISAKMP. El problema es ése en la etapa MM3 y MM4 del proceso, usted no puede seleccionar un perfil ISAKMP a menos que usted utilice una dirección IP para la identidad y las confianza-puntas porque la autenticación en el MM5 y la etapa MM6 del proceso deben ocurrir primero. Por este motivo, la política local se relaciona explícitamente con todas las confianza-puntas que se configuren en el dispositivo.


Nota: Esta información no es Cisco específico, sino que es IKEv1-specific.


Selección del perfil IKEv2 con las identidades que solapan

Antes de que los certificados múltiples para IKEv2 se describan, es importante conocer la manera que los perfiles se seleccionan cuando se utiliza la identidad de la coincidencia, que se satisface para todos los perfiles. Esto no es un escenario recomendado porque los resultados de la negociación IKEv2 dependen de los factores múltiples. Los mismos problemas existen para IKEv1 cuando se utilizan los perfiles que solapan.

Aquí está una configuración del iniciador del ejemplo 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

El direccionamiento del tipo de la identidad se utiliza para los ambos lados de la conexión. La autenticación vía los Certificados (pueden también estar las claves previamente compartidas) no es importante por este ejemplo. El respondedor tiene perfiles múltiples esa toda la coincidencia el tráfico entrante 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

El iniciador envía el tercer paquete IKEv2, y el respondedor debe elegir el perfil basado en la identidad se recibe que. La identidad es un direccionamiento del IPv4 (192.168.0.1):


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

Todos los perfiles satisfacen esta identidad debido al comando de la identidad de la coincidencia se configura que. El IOS elige el más reciente de la configuración, que es profile3 en este ejemplo:


IKEv2:found matching IKEv2 profile 'profile3'

Para verificar la orden, ingrese el comando profile crypto ikev2 de la demostración.


Nota: Incluso cuando hay un direccionamiento genérico (0.0.0.0) en el perfil, todavía se selecciona. El IOS no intenta encontrar una mejor coincidencia; intenta encontrar la primera coincidencia. Sin embargo, esto ocurre solamente porque todos los perfiles tienen el mismo comando remote de la identidad de la coincidencia configurado. Para los IKEv1 y los perfiles IKEv2 que tienen diversas reglas de la identidad de la coincidencia, la más específica se utiliza siempre. Cisco recomienda que usted no tener los perfiles configurados con la identidad de la coincidencia que solapa ordena porque es difícil predecir el perfil se selecciona que. 


En este escenario, profile3 es seleccionado por el respondedor, pero profile1 se utiliza para la interfaz del túnel. Esto hace un error aparecer cuando se negocia el ID de proxy:


*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 fluyen cuando se utilizan los Certificados

Cuando los Certificados se utilizan para IKEv2 para autenticar, el iniciador no envía el payload del pedido de certificado en el primer paquete:


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

Las respuestas del respondedor con el payload del pedido de certificado (segundo paquete) y todos los CA porque el respondedor no tiene ningún conocimiento del perfil que se debe utilizar en esta etapa. El paquete que contiene la información se envía al iniciador:


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)

El iniciador procesa el paquete y elige una confianza-punta que haga juego CA propuesto:


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

El iniciador entonces envía el tercer paquete con el pedido de certificado y el payload del certificado. Este paquete se cifra ya con el material de codificación a partir de la fase del 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)

El cuarto paquete se envía del respondedor al iniciador y contiene solamente el payload del certificado:


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)

El flujo descrito aquí es similar al IKEv1 fluye. El respondedor debe enviar el payload del pedido de certificado francamente sin el conocimiento del perfil que debe ser utilizado, que crea los mismos problemas que se describen previamente para IKEv1 (de una perspectiva del protocolo). Sin embargo, la implementación en el IOS es mejor para el IKEv2 que para el IKEv1.


Confianza-punta obligatoria IKEv2 para el iniciador

Aquí está un ejemplo de cuando un iniciador IKEv2 intenta utilizar un perfil con la autenticación certificada y no tiene ninguna confianza-punta configurada bajo ese perfil:


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

El primer paquete se envía sin ningún payload del pedido de certificado, según lo descrito previamente. La respuesta del respondedor incluye el payload del pedido de certificado para todas las confianza-puntas que se definan en el modo de configuración global. Esto es recibida por el iniciador:


*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

El iniciador no conoce la confianza-punta que se debe utilizar para firmar. Ésta es la diferencia principal cuando la implementación IKEv2 se compara al IKEv1. El iniciador IKEv2 debe tener la confianza-punta configurada bajo perfil del iniciador IKEv2, pero no es necesario para el respondedor IKEv2.

Aquí está un extracto de la referencia de comandos:

Si no hay trustpoint definido en la configuración del perfil IKEv2, el valor por defecto es validar el certificado usando todo el trustpoints que se define en la configuración global

Es posible definir diversas confianza-puntas; uno para firmar y diverso para validar. Desafortunadamente, la confianza-punta obligatoria que se configura bajo perfil IKEv2 no soluciona todos los problemas.


R2 como el iniciador IKEv2

En este ejemplo, el r2 es el iniciador 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

En este ejemplo, el r1 es el respondedor 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

Aquí, el r2 envía el primer paquete sin ningún pedido de certificado. El respondedor responde con un pedido de certificado para todas las confianza-puntas configuradas. La pedido de las cargas útiles es similar al IKEv1 y es dependiente sobre los Certificados que están instalados:


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

El primer certificado configurado en el r1 se asocia a la confianza-punta TP2, así que el primer payload del pedido de certificado está para CA que se asocia a la confianza-punta TP2. Así, el r2 la selecciona para la autenticación (primero haga juego la regla):


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

Entonces, el r2 prepara una respuesta (el paquete 3) con el payload de la petición de la certificación que se asocia a TP2. El r1 no puede confiar en el certificado puesto que se configura para la validación contra la confianza-punta 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)

Como se mencionó anteriormente, Cisco recomienda que usted no utiliza las confianza-puntas múltiples bajo un perfil IKEv2. Cuando usted utiliza las confianza-puntas múltiples, es necesario asegurarse de que los ambos lados confían en exactamente las mismas confianza-puntas. Por ejemplo, el r1 y el r2 tienen TP1 y TP2 configurados en sus perfiles.


Resumen

Esta sección proporciona un Resumen breve de la información que se describe en el documento.

El contenido del payload del pedido de certificado depende de la configuración. Si una confianza-punta específica se configura para el perfil ISAKMP y el router es el iniciador ISAKMP, después el pedido de certificado en el MM3 contiene solamente CA que se asocia a la confianza-punta. Sin embargo, si el mismo router es el respondedor ISAKMP, después el paquete MM4 que es enviado por el router incluye las cargas útiles de la petición del certificado múltiple para todas las confianza-puntas global-definidas (cuando el comando de la confianza-punta Ca no se toma en la consideración). Esto ocurre porque el respondedor ISAKMP puede determinar el perfil ISAKMP que debe ser utilizado solamente después que recibe el MM5 y el pedido de certificado que se incluye en el MM4.

El payload del pedido de certificado en el MM3 y el MM4 es importante debido a la primera regla de la coincidencia. La primera regla del emparejamiento determina la confianza-punta que se utiliza para la selección del certificado, que es necesaria para la autenticación en el MM5 y el MM6.

La orden del payload del pedido de certificado depende por orden de los Certificados que están instalados. El emisor del primer certificado que aparece en la salida del comando certificate crypto del pki de la demostración se envía primero. Este primer certificado es el más reciente se alista que.

Es posible configurar las confianza-puntas múltiples para un perfil ISAKMP. Si se realiza esto, después todas las reglas anteriores todavía se aplican.

Todos los problemas y advertencias que se describen en este documento son debido al diseño del protocolo IKEv1. La etapa de autenticación ocurre en el MM5 y el MM6, mientras que las ofertas para la autenticación (pedidos de certificado) se deben enviar en un primero tiempo (inicial) sin el conocimiento del perfil ISAKMP que debe ser utilizado. Esto no es un problema del Cisco específico y se relaciona con las limitaciones del diseño del protocolo IKEv1.

El protocolo IKEv2 es similar al IKEv1 con respecto al proceso de negociación del certificado. Sin embargo, la implementación en el IOS fuerza el uso de las confianza-puntas específicas para el iniciador. Esto no soluciona todos los problemas. Cuando las confianza-puntas múltiples se configuran para un solo perfil y una sola confianza-punta se configura en el otro lado, es todavía posible encontrar los problemas con la autenticación. Cisco recomienda que usted utiliza las configuraciones simétricas de la confianza-punta para los ambos lados de la conexión (las mismas confianza-puntas configuradas para ambos perfiles IKEv2).

Aquí están algunas NOTAS IMPORTANTES sobre la información que se describe en este documento:

  • Con las configuraciones asimétricas de la confianza-punta para los perfiles IKEv1 de los pares, el túnel pudo iniciar de solamente un lado del túnel. La configuración de la confianza-punta para el perfil IKEv1 es opcional.

  • Con las configuraciones asimétricas de la confianza-punta para los perfiles IKEv2 de los pares, el túnel pudo iniciar de solamente un lado del túnel. La configuración de la confianza-punta para el perfil IKEv2 es obligatoria para el iniciador.

  • La orden del payload del pedido de certificado depende por orden de los Certificados que aparecen en la salida del comando certificate crypto del pki de la demostración (primera coincidencia).

  • La orden del payload del pedido de certificado determina el certificado que es seleccionado por el respondedor (primer emparejamiento).

  • Cuando usted utiliza los perfiles múltiples para el IKEv1 y el IKEv2 y hace las mismas reglas de la identidad de la coincidencia configurar, es difícil predecir los resultados (demasiados factores implicados).

  • Cisco recomienda que usted utiliza las configuraciones simétricas de la confianza-punta para el IKEv1 y el IKEv2.

Información Relacionada



Document ID: 117633