Можно ли использовать PAP с TTLS на сервере RADIUS?

Мы развернули сервер Radius (Freeradius 3.x) и подключили его к нашей базе данных LDAP (ForgeRock OpenDJ).

Мы успешно настроили EAP-TTLS с действующими сертификатами и установите его как метод подключения по умолчанию. (почти все остальные настройки оставлены по умолчанию)

Однако, когда EAP-TTLS установлен, пароль передается через PAP. Я не специалист по сетям, но я читал, что PAP не защищен и не должен использоваться? (Я чувствую, что в Интернете много запутанного материала)

Если я попытаюсь войти в систему с помощью любого другого, например MS-CHAPv2, произойдет сбой с различными ошибками:

 FAILED: No NT/LM-Password.  Cannot perform authentication'

или

freeradius_1  | (22) eap_md5: ERROR: Cleartext-Password is required for EAP-MD5 authentication

Очевидно, это требует дополнительной настройки.

Вопрос в том, подходит ли нам PAP, когда у нас есть EAP-TTLS с 2019 года? Или нам стоит подумать о том, чтобы установить другой тип по умолчанию?

У нашего LDAP есть хешированные пароли (очевидно), так что у нас вообще есть другой вариант? На основе этот документ который я нашел, кажется, это наш единственный вариант.

В этом случае при условии, что сертификат, представленный сервером, правильно подтвержден запрашивающей стороной, конфиденциальность (защита от отслеживания) и целостность (защита от модификации) обеспечивается EAP-TLS / TLS.

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

Любая организация, серьезно относящаяся к безопасности, либо внедрит EAP-TLS (устраняя необходимость в пароле), либо запустит растворяемый установщик (SecureW2, Cloudpath, eduroamCAT - если это для eduroam) на своих беспроводных клиентах, чтобы правильно настроить параметры аутентификации 802.1X.

В прошлый раз, когда я проверил Windows 10, в частности, не было реализовано какое-либо закрепление сертификата / SSID, поэтому указание на то, что вы доверяли сертификату сервера во время начальной попытки аутентификации, фактически не добавляло никакой безопасности. Для последующих попыток аутентификации с другим сертификатом соискатель с радостью предоставит вам отпечаток нового сертификата без каких-либо указаний на несоответствие. Единственный способ исправить это - явно установить параметры проверки сертификата (доверенные центры сертификации, ожидаемый шаблон имени субъекта) для беспроводной сети либо вручную, либо с помощью программы установки с растворением (как упоминалось выше).

Чтобы ответить на ваш другой вопрос о том, какие внутренние методы TTLS / PEAP будут работать с LDAP, если вы используете аутентифицированные привязки LDAPv3 для аутентификации пользователя, тогда да, будут работать только PAP или GTC (см. PEAPv0 / GTC). Оба они действуют примерно одинаково.

Если вы извлекаете хэши и выполняете сравнение локально на сервере RADIUS и сохраняете хэш NT-Password для пароля пользователя, а также любой другой хэш, который вы используете, то это позволяет вам выполнять MSCHAPv2.

Честно говоря, NT-пароли используют чрезвычайно слабое хеширование (MD4), так что это почти так же плохо, как хранение открытого текста в OpenLDAP. Вам необходимо взвесить вероятность того, что ваша установка OpenLDAP будет скомпрометирована, и риск того, что все хэши будут украдены / взломаны, и вероятность того, что кто-то проведет атаку MITM, а также риск кражи подмножества паролей.

В заключение: если вы используете EAP-PWD, существует некоторая ограниченная поддержка использования хешированных копий пароля как на сервере Supplicant, так и на сервере RADIUS, но этот метод EAP широко не поддерживается за пределами сред Linux.

Я очень недоволен ситуацией, TBH, но чтобы заставить всех принять новый метод EAP, потребуются значительные усилия со стороны нескольких поставщиков.

Единственное, что можно реализовать на стороне FreeRADIUS, - это настроить «выборочные проверки» для параметров проверки сертификатов и исправить любых пользователей, которые их не выдержали. Это можно сделать путем динамической замены сертификата, представленного соискателю, на недействительный и проверки того, что соискатель возвращает правильное предупреждение (invalid_ca) на сервер RADIUS. Это приведет к сбою аутентификации (если все работает правильно), но соискатели также будут довольно быстро повторять попытку, так что, если выборочные проверки происходят довольно редко, это не слишком большая проблема.