Поддерживает ли IKEv2 аутентификацию инициатора по предварительному общему ключу _and_ password?
Я хотел бы настроить шлюз IKEv2 VPN для доступа нескольких пользователей к частной сети.
У меня есть тестовая установка, где респондент аутентифицирует себя с помощью самозаверяющего сертификата. Инициатор аутентифицируется с помощью имени пользователя и пароля.
Пара вопросов:
- Сертификат слишком сложен. Я не буду настраивать правильную PKI, поэтому самозаверяющий сертификат, который должен быть разослан каждому клиенту и настроен как доверенный, равняется предварительному общему ключу (PSK), в то время как его создание и администрирование существенно сложнее.
- Инициатор аутентифицируется только по имени пользователя и паролю, поэтому внешний злоумышленник может легко попытаться угадать слабые или скомпрометированные пароли.
За исключением развертывания правильной PKI, я бы предпочел выполнить взаимную аутентификацию хостов инициатора и ответчика через PSK. Этот ключ будет безопасно распространяться среди всех пользователей. Внешние злоумышленники не будут иметь PSK, поэтому для доступа недостаточно слабого или скомпрометированного пароля. Аутентификация по имени пользователя и паролю позволяет идентифицировать и авторизовать конкретного пользователя по существующей системе каталогов без необходимости генерирования и распространения уникальных ключей для каждого пользователя.
Это возможно с IKEv2? Насколько я могу сказать, это было возможно через Xauth в IKEv1. Но для IKEv2 я не совсем уверен: при кратком прочтении RFC 5996, раздел 2.16, похоже, это не так. Аутентификация имени пользователя и пароля будет происходить с помощью некоторого метода EAP, и:
Инициатор указывает на желание использовать EAP, пропуская полезную нагрузку AUTH из первого сообщения в обмене IKE_AUTH. (Обратите внимание, что полезная нагрузка AUTH требуется для аутентификации не-EAP и, таким образом, в остальной части этого документа не помечена как необязательная.)
Это говорит о том, что инициатор может использовать только один из EAP (имя пользователя и пароль) или PSK.
Хотя вопрос касается протокола IKEv2, я намерен реализовать ответную часть с помощью сильного свинга, поэтому любая дополнительная экспертиза там будет приветствоваться.
1 ответ
Аутентификация клиента и сервера в IKEV2 не связана. Таким образом, теоретически вы можете аутентифицировать сервер с помощью PSK, а клиент - с помощью EAP. Однако RFC заявляет следующее относительно аутентификации EAP:
Помимо аутентификации с использованием подписей с открытым ключом и общих секретов, IKE поддерживает аутентификацию с использованием методов, определенных в RFC 3748 [EAP]. Как правило, эти методы асимметричны (предназначены для аутентификации пользователя на сервере) и могут не быть взаимными. По этой причине эти протоколы обычно используются для аутентификации инициатора в ответчике и ДОЛЖНЫ использоваться в сочетании с аутентификацией ответчика для инициатора на основе открытого ключа.
Таким образом, объединение аутентификации сервера PSK с аутентификацией клиента EAP несовместимо с RFC. Тем не менее, его можно настроить с помощью strongSwan. Но обратите внимание, что большинство клиентов не разрешат эту комбинацию.
Многие клиенты Roadwarrior на самом деле вообще не поддерживают аутентификацию PSK, поскольку в таких сценариях существует потенциальная угроза безопасности, если один и тот же PSK используется с несколькими клиентами, потому что все клиенты, которые знают PSK, теоретически могут выдавать себя за сервер.
У меня есть тестовая установка, где респондент аутентифицирует себя с помощью самозаверяющего сертификата.
Почему бы не использовать Let's Encrypt?
Инициатор аутентифицируется только по имени пользователя и паролю, поэтому внешний злоумышленник может легко попытаться угадать слабые или скомпрометированные пароли.
Использование PSK для аутентификации сервера не изменит этого. Вам нужно добавить второй фактор к аутентификации клиента, чтобы что-то с этим сделать (т.е. сначала использовать сертификат или PSK, а затем выполнить EAP). Однако для этого требуется поддержка RFC 4739, которой нет у многих клиентов (хотя ее поддерживает strongSwan).