Какой уровень шифрования используется во время аутентификационной части соединения?
Вот образец /etc/ipsec.conf конфигурация.
config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no
conn ikev2
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
ike=aes256gcm16-sha384-modp3072!
esp=aes256gcm16-sha384-modp3072!
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftid=@example.com
leftcert=/etc/ipsec.d/certs/vpn-server-cert.pem
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
rightdns=1.1.1.1,1.0.0.1
rightsourceip=10.0.2.1/24
rightsendcert=never
eap_identity=%identity
Шифрование сообщений IKEv2 не имеет ничего общего с методом аутентификации. Что именно вы хотите знать?
Я пытаюсь понять, насколько безопасны учетные данные (а позже и общий секрет) при передаче на сервер. В случае HTTPS это очень хорошо задокументировано. TLS использует Диффи-Хеллман (ан асимметричный ключ алгоритм) для генерации общего секрета, который затем используется для установления канала, защищенного симметричный ключ криптография, полученная из этого общего секрета. Шифрование этого канала обычно разглашается. Например, на YouTube.com это TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (128-битное шифрование AES-GCM с 256-битным алгоритмом целостности SHA2). Я новичок в криптографии, поэтому надеюсь, что вышеизложенное верно. Теперь я не могу найти эквивалент указанной выше спецификации в контексте eap-mschapv2 с использованием openSwan. Я ожидаю, что что-то подобное происходит, но мне бы хотелось убедиться, что я полностью понимаю протокол.
Добавлены ссылки на случай, если другие захотят узнать больше о криптографии.
Основы IKEv2 очень похожи на TLS. В первых двух сообщениях (IKE_SA_INIT) два одноранговых узла согласовывают набор алгоритмов (один из них - группа Диффи-Хеллмана) и обмениваются открытыми ключами DH. Затем они получают общий секрет и последующие сообщения (IKE_AUTH, INFORMATIONAL, CREATE_CHILD_SA) обмениваются зашифрованными и защищенными. В IKE_AUTH сообщения содержат данные аутентификации (идентификаторы, подписи, сертификаты, полезные данные EAP) и информацию о первом IPsec / Child SA (например, алгоритмы и селекторы трафика).
При использовании таких методов аутентификации, как EAP-MSCHAPv2, которые потенциально основаны на слабых паролях пользователей и подвержены активным атакам со стороны посредника, важно использовать надежный метод аутентификации для ответчика (например, аутентификация с открытым ключом) и для проверки личности респондента перед передачей любых (хешированных) секретов. Например, клиент может убедиться, что доменное имя или IP-адрес подтверждены сертификатом респондента, который, конечно же, должен быть действительным и надежным.
В отличие от TLS, IKEv2 не использует предопределенные наборы шифров. Алгоритмы различных типов преобразования (шифрование, целостность, PRF, DH) можно относительно свободно комбинировать (есть некоторые ограничения, например, предложения с алгоритмами AEAD, такими как AES-GCM, не могут содержать алгоритмы целостности). Как упоминалось выше, эти параметры для IKE_SA передаются открыто в IKE_SA_INIT Сообщения. Однако параметры для CHILD_SA передаются только в зашифрованном виде (обратите внимание, что нет отдельного обмена DH для первого CHILD_SA, созданного с помощью IKE_SA, только ключи для более поздних CHILD_SA могут быть необязательно основаны на обмене DH, в противном случае они получены из ключи IKE).
Полное описание протокола IKEv2 можно найти в RFC 7296.