Кратко

  • RFC 9965 резервирует eap.arpa для NAI, запрашивающих определённый путь provisioning и ограниченную, ещё не аутентифицированную связность.
  • Запрос, выбор EAP-метода, аутентификация сервера, применение ограниченной сети, выдача учётных данных и обычный допуск — разные записи и разные решения.

Неизвестное устройство предъявляет идентификатор, оканчивающийся на eap.arpa. Сеть может прочитать его как просьбу помочь получить учётные данные. Она не может прочитать его как сами учётные данные. В этом и состоит сдержанная ценность RFC 9965, The eap.arpa. Domain and Extensible Authentication Protocol Provisioning.

RFC определяет EAP Provisioning Identifier, или EPI: NAI, чей realm является поддоменом eap.arpa.. Realm намеренно не привязан к конкретной организации. Его не следует автоматически проксировать через существующую AAA-инфраструктуру или разрешать обычным динамическим обнаружением пиров. При этом организации не запрещено решить вопрос маршрутизации локально. Общий синтаксис сообщает, как пир просит метод provisioning; принимающий оператор всё равно решает, принимать ли запрос, куда его направлять и на каких доказательствах основывать обработку.

Поэтому строка realm — слабое свидетельство. Она может подтвердить, что пир послал конкретный запрос при обмене EAP identity. Она не подтверждает владельца устройства, ответственную организацию, обработавший запрос backend или завершение метода аутентификации. Журнал, который превращает @method.eap.arpa в «доверенное устройство», незаметно заменяет одно наблюдаемое сообщение несколькими ненаблюдаемыми решениями.

RFC 9965 прямо описывает состояние до этих решений. Реализация должна считать использующих EPI пиров недоверенными. После принятия метода provisioning пир должен находиться в ограниченной сети, например captive portal; эта сеть не должна позволять неограниченный доступ. Безопасная сеть provisioning разрешает ожидаемый трафик и блокирует всё остальное. Схема, которая блокирует лишь некоторые плохие адресаты, оставляет более широкую и хуже проверяемую поверхность.

Границу метода также нельзя перепрыгнуть. EPI выбирает запрошенный метод provisioning. Если EAP-сервер принимает запрос, предложенный метод обязан соответствовать методу, связанному с EPI; лишь затем продолжается обычный автомат состояний EAP. RFC 3748 определяет EAP как фреймворк аутентификации с несколькими методами и предупреждает: даже аутентифицированному пиру может быть отказано в доступе по политике, из-за лимита сессии или иных причин. Выбор метода не является ни успехом EAP, ни общим разрешением.

Аутентификация сервера — отдельный слой. RFC 9965 требует, чтобы каждый метод provisioning под eap.arpa. описывал, как аутентифицируется сервер, и рекомендует EAP на базе TLS там, где он обеспечивает аутентификацию сервера, целостность и конфиденциальность. Это требование к проектированию метода, а не доказательство того, что конкретная сессия проверила определённый сертификат. Для аудита нужны раздельные записи: запрос EPI, локальное решение о маршрутизации, выбранный метод, свидетельство аутентификации сервера, фактически применённое правило ограниченной сети, решение об учётных данных и последующее решение о доступе.