Цитирование Википедия:
Он предлагает минимальную безопасность; хеш-функция MD5 уязвима для атак по словарю и не поддерживает генерацию ключей, что делает ее непригодной для использования с динамическим WEP или WPA / WPA2 Enterprise
Однако в Википедии EAP-MD5 обсуждается в контексте беспроводной аутентификации. Если я правильно понимаю, это не угроза безопасности в strongSwan, поскольку аутентификация между клиентом и сервером зашифрована. Я прав?
Да, в контексте strongSwan или в более общем смысле IKEv2, сообщения EAP передаются в зашифрованном виде при обмене IKE_AUTH. Атаки типа «злоумышленник посередине» предотвращаются путем первой аутентификации сервера с помощью сертификатов с использованием стандартной аутентификации IKEv2. Соображения безопасности в IKEv2 RFC на самом деле говорят:
Реализация, использующая EAP, ДОЛЖНА также использовать аутентификацию сервера на основе открытого ключа для клиента до начала аутентификации EAP ...
Это так, если не используется метод EAP с взаимной аутентификацией (например, EAP-TLS, но не EAP-MD5) и клиент не поддерживает EAP-only аутентификация.
Если аутентификация EAP не завершена на сервере VPN, но, например, отдельный сервер RADIUS, следует учитывать, что связь между этими двумя, как правило, не зашифрована. Чтобы не допустить утечки информации туда, также можно использовать EAP-MD5 в других методах EAP (например, EAP-TTLS или EAP-PEAP), которые обеспечивают туннель TLS, в котором сообщения EAP-MD5 транспортируются на сервер аутентификации. Это также позволяет клиенту аутентифицировать этот сервер, что невозможно только с EAP-MD5, поскольку он не обеспечивает взаимную аутентификацию. Комбинирование таких методов туннелирования EAP с простой аутентификацией пользователя также довольно распространено для варианта использования WiFi (например, EAP-PEAP / EAP-MSCHAPv2).