Безопасность и VPN : Протокол ISAKMP

IOS IKEv1 и процессы обмена пакетами IKEv2 для профилей с нескольками серверов сертификатов

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает Версию 1 (IKEv1) Обмена ключами между сетями и процессы обмена пакетами второй версии протокола Internet Key Exchange (IKEv2), когда проверка подлинности сертификата используется и возможные проблемы, которые могли бы произойти.

Вот список предметов, которые описаны в этом документе:

  • Условия выбора сертификата для инициатора Протокола IKE и респондента IKE
  • Условия соответствия профиля IKE, когда со множественными профилями IKE совпадают (для наложения и сценариев неналожения)
  • Настройки по умолчанию и поведение, когда никакие точки доверия не используются под профилями IKE
  • Различия между IKEv1 и IKEv2 в отношении профиля и условий выбора сертификата

Примечание: Для получения дополнительной информации о том, как устранять определенную проблему, обратитесь к корректному разделу. Кроме того, краткое изложение предоставлено в конце этого документа.


Внесенный Михалом Гаркарзом, специалистом службы технической поддержки Cisco.

Предварительные условия


Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • Конфигурация VPN Cisco IOS®
  • IKEv1 и протоколы IKEv2 (обмен пакетами)

Используемые компоненты

Сведения в этом документе основываются на Cisco IOS Version15.3T.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.


Общие сведения

Проблемы, которые описаны в этом документе, возникают, когда используются множественные точки доверия и множественные профили IKE.

Начальные примеры, которые используются в этом документе, имеют туннель между локальными сетями (LAN-to-LAN) IKEv1 с двумя точками доверия на каждом маршрутизаторе. Сначала, могло бы казаться, что конфигурация корректна. Однако VPN-туннель может инициироваться только с одной стороны соединения из-за способа, которым команда ca trust-point используется для поведения профиля Протокола ISAKMP и для заказа зарегистрированных сертификатов в локальном хранилище.

Когда маршрутизатор является инициатором ISAKMP, другое поведение настроено с командой ca trust-point для профиля ISAKMP. Проблема могла бы произойти, потому что инициатор ISAKMP знает о профиле ISAKMP от запуска, таким образом, команда ca trust-point, которая настроена для профиля, может влиять на информационное наполнение для запроса сертификата в Пакете Основного режима 3 (MM3). Однако, когда маршрутизатор является респондентом ISAKMP, он связывает входящий трафик с определенным профилем ISAKMP после того, как он получает Пакет Основного режима 5 (MM5), который включает ID IKE, который необходим для создания связывания. Это - то, почему не возможно применить любую команду ca trust-point для Пакета Основного режима 4 пакета (MM4), потому что профиль не определен перед MM5.

Заказ сертификата requestpayload в MM3 и MM4 и влиянии на целый процесс согласования объяснен в этом документе, а также причине, что это только позволяет соединению быть установленным с одной стороны VPN-туннеля.

Вот сводка способов поведения инициатора и респондента IKEv1:


 Инициатор IKEv1Респондент IKEv1
Отправьте запросПередает конкретные запросы только за точками доверия, которые настроены под профилем Отправляет запросы для всех доступных точек доверия
Проверьте запросПроверяет против определенных точек доверия, которые настроены под профилемПроверяет против определенных точек доверия, которые настроены под профилем


Cisco рекомендует не использовать команду ca trust-point для респондентов ISAKMP, которые имеют множественные профили ISAKMP и используют глобально настроенные точки доверия. Для инициаторов ISAKMP со множественными профилями ISAKMP Cisco рекомендует сузить процесс выбора сертификата к команде ca trust-point в каждом профиле.

Протокол IKEv2 имеет те же проблемы как протокол IKEv1, но другое поведение команды точки доверия pki помогает предотвращать возникновение проблем. В то время как команда ca trust-point является дополнительной для инициатора IKEv1, это вызвано тем, что команда точки доверия pki является обязательной для инициатора IKEv2. При некоторых обстоятельствах (множественные точки доверия под одним профилем), могли бы произойти ранее описанные проблемы. Поэтому Cisco рекомендует использовать симметричные конфигурации точки доверия для обеих сторон соединения (те же точки доверия, настроенные под обоими из профилей IKEv2).


Топология

Это - топология общего назначения, которая используется для всех примеров в этом документе.


Примечание: Маршрутизатор 1 (R1) и Маршрутизатор 2 (R2) используют Виртуальные туннельные интерфейсы (VTIs) для доступа к loopback. Эти VTIs защищены IPSec.


Для этого примера IKEv1 каждый маршрутизатор имеет две точки доверия для каждого Центра сертификации (CA), и сертификаты для каждой из точек доверия зарегистрированы.

Когда R1 является инициатором ISAKMP, туннель выполняет согласование правильно, и трафик защищен. Это ожидаемое состояние. Когда R2 является инициатором ISAKMP, сбоями согласования Phase1.


Примечание: Для примеров IKEv2 в этом документе, топологии и адресации совпадает с показанным пример IKEv1.


Процесс обмена пакетами

В этом разделе описываются IKEv1 и варьирования конфигурации IKEv2, которые используются для процесса обмена пакетами и возможных проблем, которые могли бы возникнуть.


IKEv1 с нескольками серверов сертификатов

Вот сеть R1 и конфигурация VPN для IKEv1 с нескольками серверов сертификатов:


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

Вот сеть R2 и конфигурация VPN для IKEv1 с нескольками серверов сертификатов:


crypto isakmp policy 10
 encr 3des
 hash md5
 group 2

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

ip route 192.168.100.0 255.255.255.0 10.0.0.1

В данном примере R1 имеет две точки доверия: каждый использует IOSCA1 и второе использование IOSCA2:


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

В данном примере R2 также имеет две точки доверия: каждый использует IOSCA1 и второе использование IOSCA2:


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

Важно обратить внимание на одиночное различие в этих конфигурациях: профиль R1 ISAKMP использует команду ca trust-point для точки доверия IOSCA1, которая указывает, что R1 доверяет только сертификатам, которые проверены той определенной точкой доверия. Напротив, R2 доверяет всем сертификатам, которые проверены всеми глобально определенными точками доверия.


R1 как инициатор IKEv1

Вот команды отладок и для R1 и для R2:

  • Debug crypto isakmp R1#
  • Debug crypto ipsec R1#
  • Проверка pki debug crypto R1#

Здесь, R1 инициирует туннель и передает сертификат requestin MM3:


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

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

Важно заметить, что пакет содержит только один запрос сертификата, который является только для точки доверия IOSCA1. Это - нормальное поведение с текущей конфигурацией профиля ISAKMP (CN=CA1, O=cisco, O=com). Никакие другие запросы сертификата не передаются, который можно проверить со Встроенной функцией Захвата пакета:



Когда R2 получает пакет, он начинает обрабатывать запрос сертификата, который создает соответствие, которое определяет точку доверия и cвязанный сертификат, который используется для аутентификации в MM5. Заказ процесса совпадает с информационным наполнением запроса сертификата в Пакете ISAKMP. Это означает, что используется первое соответствие. В этом сценарии существует только одно соответствие, так как R1 настроен с определенной точкой доверия и передает только один запрос сертификата, который привязан к точке доверия.


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

Впоследствии, R2 готовит MM4. Это - пакет, который содержит запрос сертификата для всех доверяемых точек доверия. Так как R2 является респондентом ISAKMP, всем глобально определенным точкам доверия доверяют (конфигурация ca trust-point не проверена). Две из точек доверия определены вручную (IOSCA1 и IOSCA2), и остальные предопределены.


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

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

Можно проверить пакет с Wireshark. Пакет MM4 от R2 содержит семь записей запроса сертификата:



Затем R1 получает MM4 от R2 с полями запроса несколька серверов сертификатов:


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

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

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

Правило первого соответствия о R1 совпадает с первым запросом сертификата с точкой доверия IOSCA1. Это решает, что R1 использует сертификат, который привязан к точке доверия IOSCA1 для аутентификации в MM5. Полное доменное имя (FQDN) используется в качестве ID IKE. Это происходит из-за self-identity fqdn конфигурация в профиле 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

MM5 получен и обработан R2. Полученный ID (R1.cisco.com) IKE совпадает с профилем ISAKMP prof1. Полученный сертификат тогда проверен, и аутентификация успешна:


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

Затем R2 готовит MM6 с сертификатом, который привязан к 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

Пакет получен R1, и R1 проверяет сертификат и аутентификацию:


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

Это завершает Фазу 1. О фазе 2 выполняют согласование, как обычно. Туннель установлен успешно, и трафик защищен.


R2 как инициатор IKEv1

Данный пример описывает процесс, когда R2 инициирует тот же туннель IKEv1 и объясняет, почему это не установлено.


Примечание: Части журналов удалены для фокусирований только на различиях относительно примера, представленного в предыдущем разделе.


R2 передает MM3 с семью информационными наполнениями запроса сертификата, потому что R2 не привязывали точку доверия к профилю ISAKMP (всем точкам доверия доверяют):


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

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

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

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

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

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

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

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

Когда R1 получает пакет от R2, это обрабатывает запрос сертификата и совпадает с точкой доверия IOSCA1, которая определяет сертификат, который передается в 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

Впоследствии, R1 готовит пакет MM4 с информационным наполнением запроса сертификата. Теперь существуют информационные наполнения запроса несколька серверов сертификатов:


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

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

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

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

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

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

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

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

Проверьте журналы со встроенной функцией захвата пакетов (EPC) и Wireshark:



Даже при том, что R1 настроен для одиночной точки доверия (IOSCA1) в профиле ISAKMP, существуют отправленные запросы несколька серверов сертификатов. Это происходит, потому что команда ca trust-point в профиле ISAKMP определяет информационное наполнение запроса сертификата, но только когда маршрутизатор является инициатором сеанса ISAKMP. Если маршрутизатор является респондентом, существуют информационные наполнения запроса несколька серверов сертификатов для всех глобально определенных точек доверия, потому что R1 еще не знает профиль ISAKMP, который используется для сеанса IKE.

Входящий сеанс IKE связан с определенным профилем ISAKMP после приема MM5, который включает ID IKE. Впоследствии, команда match identity для определенного профиля связывает сеанс IKE с профилем. Однако маршрутизатор не может определить это до сих пор. Могли бы быть множественные профили ISAKMP с другими командами ca trust-point, настроенными для каждого профиля.

Поэтому R1 должен передать запрос сертификата за всеми глобально настроенными точками доверия.

Обратитесь к Справочнику по командам для команды ca trust-point:

IKE инициирования маршрутизатора и маршрутизатор, отвечающий на запрос IKE, должны иметь симметричные конфигурации точки доверия. Например, отвечающий маршрутизатор (в Основном режиме IKE) выполняющее шифрование сигнатуры RSA и аутентификация могли бы использовать точки доверия, которые были определены в глобальной конфигурации при передаче информационных наполнений REQ CERT. Однако маршрутизатор мог бы использовать ограниченный список точек доверия, которые были определены в профиле ISAKMP для Проверки сертификата. Если узел (инициатор IKE) настроен для использования сертификата, точка доверия которого находится в глобальном списке отвечающего маршрутизатора, но не в профиле ISAKMP отвечающего маршрутизатора, сертификат отклонен. (Однако, если маршрутизатор инициирования не знает о точках доверия в глобальной конфигурации отвечающего маршрутизатора, сертификат может все еще быть заверен.)

Теперь проверьте данные пакета MM4 для обнаружения первого информационного наполнения запроса сертификата:



Пакет MM4, который передан от R1, включает точку доверия IOSCA2 в первое информационное наполнение запроса сертификата из-за заказа, в котором установлены сертификаты; первый подписан точкой доверия 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>

Сделайте сравнение с пакетом MM3, который передан от R2, когда точка доверия IOSCA1 включена в первое информационное наполнение запроса сертификата:


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

Теперь R2 получает пакет MM4 от R1 и начинает обрабатывать запрос сертификата. Первое информационное наполнение запроса сертификата совпадает с точкой доверия IOSCA2:


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

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

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

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

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

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

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

Когда R2 готовит пакет MM5, он использует сертификат, который привязан к точке доверия IOSCA2:


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

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

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

Пакет MM5 получен R1. Поскольку R1 доверяет только точке доверия IOSCA1 (для prof1 профиля ISAKMP), сбои проверки достоверности сертификата:


*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

Эта конфигурация работает, если заказ хранилища сертификатов на R1 является другим, потому что первый отображенный сертификат подписан точкой доверия IOSCA1. Кроме того, первое информационное наполнение запроса сертификата в MM4 является точкой доверия IOSCA1, которая тогда выбрана R2 и проверена успешно на R1 в MM6.


IKEv1 без Команды ca trust-point в Профиле

Для сценариев со множественными профилями и точками доверия, но без определенной конфигурации точки доверия в профилях, нет никаких проблем, потому что нет никакой проверки определенных точек доверия, определенных настройкой команды ca trust-point. Однако процесс выбора не мог бы быть очевидным. Зависящий от маршрутизатора, который является инициатором, другие сертификаты выбраны для процесса проверки подлинности относительно заказа хранилища сертификатов.

Иногда сертификат может поддерживаться только одной стороной соединения, такой как в x509 Версии 1, которая не является типичной хэш-функцией, которая используется для подписания. VPN-туннель мог бы быть установлен только с одной стороны соединения.


Ссылка на RFC для IKEv1

Вот надрез от RFC4945:

3.2.7.1. Определение центров сертификации

При запросе внутриполосного обмена материалами для кодирования реализаций SHOULD генерирует CERTREQs для каждой одноранговой трастовой привязки, которую локальная политика явно считает доверяемым во время данного обмена.

RFC не ясен. Локальная политика явно могла бы коснуться команды ca trust-point, которая настроена в crypto ISAKMP profile. Проблема состоит в том, что в MM3 и этапе MM4 процесса, вы не можете выбрать профиль ISAKMP, пока вы не используете IP-адрес для идентичности и точек доверия, потому что аутентификация в MM5 и этапе MM6 процесса должна произойти сначала. Поэтому локальная политика явно касается всех точек доверия, которые настроены на устройстве.


Примечание: Эта информация не определяема Cisco, но это IKEv1-специфично.


Выбор Профиля IKEv2 с Личностями то Наложение

Перед нескольками серверов сертификатов для IKEv2 описан, важно знать способ, которым выбраны профили, когда match identity используется, который удовлетворен для всех профилей. Это не рекомендуемый сценарий, потому что результаты согласования IKEv2 зависят от множественных факторов. Те же проблемы существуют для IKEv1, когда профили, что используется наложение.

Вот является пример конфигурацией инициатора IKEv2:


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

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

ip route 192.168.200.1 255.255.255.255 10.0.0.2

Идентификационный адрес типа используется для обеих сторон соединения. Аутентификация через сертификаты (могут также быть предварительные общие ключи) не важна для данного примера. У респондента есть множественные профили что все соответствие входящий трафик IKEv2:


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

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

ip route 192.168.100.1 255.255.255.255 10.0.0.1

Инициатор передает третий пакет IKEv2, и респондент должен выбрать профиль на основе идентичности, которая получена. Идентичностью является IPv4 address (192.168.0.1):


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

Все профили удовлетворяют эту идентичность из-за команды match identity, которая настроена. IOS выбирает последний в конфигурации, которая является profile3 в данном примере:


IKEv2:found matching IKEv2 profile 'profile3'

Для подтверждения заказа введите показ крипто-команда профиля ikev2.


Примечание: Даже когда существует адрес общего назначения (0.0.0.0) в профиле, он все еще выбран. IOS не пытается найти лучшее соответствие; это пытается найти первое соответствие. Однако это только происходит, потому что все профили имеют того же match identity удаленная настроенная команда. Для IKEv1 и профилей IKEv2, которые имеют другие правила match identity, всегда используется самый определенный. Cisco рекомендует не настроить профили с перекрывающейся командой match identity, потому что трудно предсказать профиль, который выбран. 


В этом сценарии profile3 выбран респондентом, но profile1 используется для туннельного интерфейса. Когда о Proxy Id выполняют согласование, это вызывает ошибку появиться:


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

Поток IKEv2, когда Используются Сертификаты

Когда сертификаты используются для IKEv2 для аутентификации, инициатор не передает информационное наполнение запроса сертификата в первом пакете:


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

Респондент отвечает с информационным наполнением запроса сертификата (второй пакет) и все CAs, потому что у респондента нет знания профиля, который должен использоваться на данном этапе. Пакет, который содержит информацию, передан инициатору:


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

Инициатор обрабатывает пакет и выбирает точку доверия, которая совпадает с предложенным CA:


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

Инициатор тогда передает третий пакет и с запросом сертификата и с информационным наполнением сертификата. Этот пакет уже зашифрован с материалом для кодирования от фазы 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)

Четвертый пакет передается от респондента инициатору и содержит только информационное наполнение сертификата:


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

Поток, описанный здесь, подобен потоку IKEv1. Респондент должен передать информационному наполнению запроса сертификата переднюю сторону без ведома профиля, который должен использоваться, который создает те же проблемы, которые ранее описаны для IKEv1 (с точки зрения протокола). Однако реализация на IOS лучше для IKEv2, чем для IKEv1.


IKEv2 обязательная точка доверия для инициатора

Вот пример того, когда инициатор IKEv2 пытается использовать профиль с проверкой подлинности сертификата и не имеет никакой точки доверия, настроенной под тем профилем:


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

Первый пакет передан без любого информационного наполнения запроса сертификата, как ранее описано. Ответ от респондента включает информационное наполнение запроса сертификата для всех точек доверия, которые определены в Режиме глобальной конфигурации. Это получено инициатором:


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

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

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

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

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

Инициатор не знает точку доверия, которая должна использоваться для подписания. Когда реализация IKEv2 по сравнению с IKEv1, это - основное различие. Инициатору IKEv2 нужно было настроить точку доверия под профилем инициатора IKEv2, но необязательно для респондента IKEv2.

Вот выборка от Справочника по командам:

Если нет никакой точки доверия, определенной в настройке профиля IKEv2, по умолчанию должен проверить сертификат с помощью всех точек доверия, которые определены в глобальной конфигурации

Возможно определить другие точки доверия; тот для подписания и другой для проверки. К сожалению, обязательная точка доверия, которая настроена под профилем IKEv2, не решает все проблемы.


R2 как инициатор IKEv2

В данном примере R2 является инициатором IKEv2:


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

В данном примере R1 является респондентом IKEv2:


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

Здесь, R2 передает первый пакет без любого запроса сертификата. Респондент отвечает запросом сертификата для всех настроенных точек доверия. Заказ информационных наполнений подобен IKEv1 и зависит от сертификатов, которые установлены:


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

Первый настроенный сертификат на R1 привязан к точке доверия TP2, таким образом, первое информационное наполнение запроса сертификата для CA, который привязан к точке доверия TP2. Таким образом R2 выбирает его для аутентификации (сначала правило соответствия):


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

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

Затем R2 готовит ответ (пакет 3) с информационным наполнением запроса сертификации, которое привязано к TP2. R1 не может доверять сертификату, так как это настроено для проверки против точки доверия TP1:


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

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

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

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

Как ранее упомянуто, Cisco рекомендует не использовать множественные точки доверия под одним профилем IKEv2. При использовании множественных точек доверия необходимо гарантировать, что обе стороны доверяют точно тем же точкам доверия. Например, и R1 и R2 имеют и TP1 и TP2, настроенный в их профилях.


Сводка

Этот раздел предоставляет краткое резюме информации, которая описана в документе.

Содержание информационного наполнения запроса сертификата зависит от конфигурации. Если определенная точка доверия настроена для профиля ISAKMP, и маршрутизатор является инициатором ISAKMP, то запрос сертификата в MM3 содержит только CA, который привязан к точке доверия. Однако, если то же маршрутизатор является респондентом ISAKMP, то пакет MM4, который передан маршрутизатором, включает информационные наполнения запроса несколька серверов сертификатов для всех глобально определенных точек доверия (когда команда ca trust-point не учтена). Это происходит, потому что респондент ISAKMP может определить профиль ISAKMP, который должен использоваться только после того, как он получает MM5 и запрос сертификата, который включен в MM4.

Информационное наполнение запроса сертификата в MM3 и MM4 важно из-за первого правила соответствия. Первое правило соответствия определяет точку доверия, которая используется для выбора сертификата, который необходим для аутентификации в MM5 и MM6.

Заказ информационного наполнения запроса сертификата зависит от заказа сертификатов, которые установлены. Отправитель первого сертификата, который появляется в выходных данных показа крипто-команда сертификата pki, передается сначала. Этот первый сертификат является последним, который зарегистрирован.

Возможно настроить множественные точки доверия для профиля ISAKMP. Если это выполнено, то все предыдущие правила все еще применяются.

Все проблемы и предупреждения, которые описаны в этом документе, происходят из-за дизайна протокола IKEv1. Этап аутентификации происходит в MM5 и MM6, в то время как предложения по аутентификации (запросы сертификата) должны быть переданы на более раннем этапе (передняя сторона) без ведома профиля ISAKMP, который должен использоваться. Это не определяемая Cisco проблема и отнесено к ограничениям дизайна протокола IKEv1.

Протокол IKEv2 подобен IKEv1 в отношении процесса согласования сертификата. Однако реализация на IOS вызывает использование определенных точек доверия для инициатора. Это не решает все проблемы. Когда множественные точки доверия настроены для одиночного профиля, и одиночная точка доверия настроена с другой стороны, все еще возможно встретиться с проблемами с аутентификацией. Cisco рекомендует использовать симметричные конфигурации точки доверия для обеих сторон соединения (те же точки доверия, настроенные для обоих из профилей IKEv2).

Вот некоторые важные замечания об информации, которая описана в этом документе:

  • С асимметричными конфигурациями точки доверия для профилей IKEv1 узлов туннель мог бы инициировать только с одной стороны туннеля. Конфигурация точки доверия для профиля IKEv1 является дополнительной.

  • С асимметричными конфигурациями точки доверия для профилей IKEv2 узлов туннель мог бы инициировать только с одной стороны туннеля. Конфигурация точки доверия для профиля IKEv2 является обязательной для инициатора.

  • Заказ информационного наполнения запроса сертификата зависит от заказа сертификатов, которые появляются в выходных данных показа крипто-команда сертификата pki (первое соответствие).

  • Заказ информационного наполнения запроса сертификата определяет сертификат, который выбран респондентом (первое соответствие).

  • Когда вы используете множественные профили для IKEv1 и IKEv2 и имеете те же настроенные правила match identity, трудно предсказать результаты (слишком много включенных факторов).

  • Cisco рекомендует использовать симметричные конфигурации точки доверия и для IKEv1 и для IKEv2.

Дополнительные сведения


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 117633