Кратко

  • Успешный метод EAP может подтвердить ограниченный результат аутентификации, тогда как политика доступа, атрибуты AAA, действия аутентификатора и канал данных нижнего уровня дают собственные результаты.
  • Надёжная запись о доступе хранит итог метода, внешний итог EAP, пакет RADIUS, решение об авторизации, передачу ключа, защищённую ассоциацию и первое работоспособное соединение как отдельные подтверждения.

Самая показательная неполадка EAP не обязательно начинается с неверного пароля. Клиент может успешно завершить строгий метод с сертификатом, сервер — принять удостоверение, а журнал — отметить успех. Тем не менее пользователь не попадает в сеть: политика запрещает ещё один сеанс, запрошенный VLAN не поддерживается, ключ доставлен другому аутентификатору либо защищённая ассоциация нижнего уровня так и не создана. Фраза «аутентификация прошла» остаётся верной на одном этапе и опасно неполной применительно ко всему сеансу.

Это разделение заложено в RFC 3748, стандарте 2004 года, определившем Extensible Authentication Protocol. Бернард Абоба — один из пяти его авторов наряду с Larry Blunk, John Vollbrecht, James Carlson и редактором Henrik Levkowetz. Коллективное авторство существенно: EAP намеренно спроектирован как каркас аутентификации, а не как универсальная система управления доступом.

Успех метода — подтверждение с узкими границами

В EAP различаются клиент, аутентификатор и EAP-сервер. При сквозной передаче устройство доступа пересылает обмен EAP через AAA в серверную систему, не выполняя метод самостоятельно. Поэтому сервер может знать, что метод завершён, тогда как устройству доступа требуется отдельное сообщение о разрешённой услуге и о том, способно ли оно эту услугу предоставить.

Внешнее сообщение EAP Success имеет код 3, не содержит дополнительных данных, не подтверждается клиентом и не передаётся повторно. RFC 3748 также требует от клиента отбросить заготовленный Success, если тот пришёл раньше разрешённой методом точки завершения. В некоторых условиях сигнал нижнего уровня способен заменить потерянный внешний Success. Эти свойства показывают: само наличие отметки об успехе ещё не доказывает, что канал данных открыт.

Стандарт прямо допускает отказ уже аутентифицированному клиенту по правилам политики — например, из-за ограничения числа сеансов. На авторизацию способны повлиять и прокси AAA на пути сообщения. Проверка удостоверения отвечает на вопрос, кто принят данным методом. Право воспользоваться конкретной услугой сейчас определяется отдельно.

Для NAS решающим остаётся тип пакета RADIUS

RFC 3579 проводит чёткую эксплуатационную границу: NAS обязан принимать решение о доступе только по типу пакета RADIUS — Access-Accept или Access-Reject, — а не по вложенному результату EAP. Сервер не должен посылать Access-Reject вместе с EAP Success. Но если NAS всё же получает такую противоречивую комбинацию, он отказывает в доступе, хотя клиент может считать аутентификацию успешной. Это аномалия, которую нужно обнаруживать, а не обычная ветвь процесса.

Даже Access-Accept не завершает всю цепочку. Пакет может содержать тип услуги, VLAN, фильтры или ограничения сеанса. Если запрошена известная услуга, которую NAS не поддерживает, операция должна закончиться отказом, а не незаметной выдачей другого доступа. Фаза аутентификации завершена, но выполнение авторизации всё ещё зависит от возможностей устройства и проверяемого локального состояния.

На эксплуатационном экране поэтому нужны как минимум четыре строки: результат метода EAP, внешний результат EAP, тип пакета RADIUS и локальное решение о применении. Один зелёный индикатор стирает разницу между неверным удостоверением, отказом политики, неподдерживаемым атрибутом и противоречивым ответом.

Экспорт ключа не создаёт канал данных

RFC 5247 продолжает цепочку от результата метода к управлению ключами EAP. Метод может экспортировать MSK, однако этот факт не доказывает, что ключ попал правильному получателю, привязан к нужному аутентификатору и сеансу, что из него выведены и установлены временные ключи или что защищённая ассоциация завершена. У каждого перехода свой контекст и своё подтверждение.

Требования безопасности RFC 3748 предписывают связывать производные ключи с участниками, завершившими аутентификацию. Без этой связи журнал метода может выглядеть безупречно, а канал данных оставаться уязвимым к подмене, имитации или повтору. Статуса «MSK экспортирован» недостаточно: после него нужно подтвердить получателя и контекст, затем состояние порта и фактический трафик.

RFC 5216 проводит ту же границу для EAP-TLS. Проверка цепочки сертификатов необходима, но реализация должна дополнительно определить, уместны ли представленные идентификаторы и разрешены ли они для EAP-TLS именно в этой среде. Криптографическая достоверность — вход авторизации, а не универсальная замена решения о доступе.

Объявленное имя сети тоже может быть неверным

Одни учётные данные могут действовать в нескольких услугах. Отсюда возникает другой риск: злоумышленный или неверно настроенный аутентификатор объявляет одну сеть, а подключает клиента к другой. RFC 6677 называет это проблемой лживого NAS или провайдера. Привязка к каналу позволяет клиенту защищённым способом передать наблюдения об объявленной услуге EAP-серверу, чтобы тот сравнил их со сведениями от аутентификатора и собственными ожиданиями.

Привязка к каналу — не абстрактное обещание, будто клиент «знает сеть», а сравнение конкретных входных данных. В записи должны остаться увиденное клиентом, заявление NAS, ожидание серверной системы, защищённый метод передачи и результат сопоставления. Без них действительное удостоверение и сильный метод могут привести к не той услуге.

Подтверждение доступа нужно собирать по порядку

Полезный эксплуатационный журнал начинается до аутентификации: обнаруженное имя сети, намерение клиента, идентификатор аутентификатора и порт доступа. Затем фиксируются выбранный метод EAP, его защищённый результат, идентификаторы клиента и сервера, внешний результат EAP, тип пакета RADIUS, атрибуты авторизации и локальное решение NAS о поддержке. За ними следуют экспорт и получатель ключа, журнал защищённой ассоциации и идентификаторы установленных ключей. Лишь после этого записываются состояние контролируемого порта, конфигурация IP, первое работоспособное соединение, учёт либо последующее отключение.

Каждый элемент отвечает на вопрос уже, чем «вышел ли пользователь в интернет?». Такая детализация отличает отвергнутое удостоверение от действительного, остановленного политикой; успешную авторизацию — от неподдерживаемой услуги; завершённый метод — от отсутствующего ключа канала данных.

Источники