Кратко

  • RFC 5216 задаёт сертификатную аутентификацию EAP-TLS и вывод ключей. Валидная цепочка, CertificateVerify и Finished устанавливают узкие криптографические факты, но не создают VLAN, не ставят ACL и не открывают контролируемый порт.
  • Архитектура EAP и AAA не смешивает этапы: после успешной аутентификации авторизация может быть отклонена, NAS может не суметь предоставить разрешённую услугу, а владение ключевым материалом само по себе не доказывает право его иметь.
  • Эксплуатации нужна связанная цепочка квитанций: политика сертификата, результат EAP, решение AAA, исполнение на NAS и наблюдаемый трафик. Один зелёный статус «сертификат принят» не может отвечать за всё, что происходит дальше.

Где именно оборвалась правильная последовательность

Рассмотрим специально сконструированное событие доступа. В 08:14:02 клиент проверяет цепочку и имя сертификата EAP-сервера, а сервер проверяет сертификат клиента. CertificateVerify подтверждает владение соответствующими закрытыми ключами. Сообщения Finished связывают стороны с одним защищённым транскриптом. Криптографический монитор становится зелёным.

В 08:14:03 backend сопоставляет удостоверенную личность с NAS, портом и запрошенной услугой. Он выдаёт условное разрешение для определённой роли и VLAN. Второй монитор становится зелёным.

В 08:14:04 устройство доступа обнаруживает, что в нужном forwarding context такой VLAN нет. Применить разрешение невозможно, поэтому контролируемый порт остаётся закрытым. DHCP не начинается, IPv6-соседство не возникает, через границу не проходит ни одного пакета приложения.

В 08:14:20 сводная панель, использующая только первые два события, показывает «EAP-TLS success». Это не выдумка, а опасное сокращение: корректные сведения об идентичности и намерении политики стали утверждением о выданной услуге.

Сцена не описывает реального производителя, оператора или инцидент. Она соединяет границы, прямо обозначенные в RFC 5216, RFC 3748, RFC 3579 и модели ключей EAP. Все отдельные компоненты могут сработать корректно, а общий вывод — нет.

Три доказательства внутри TLS

EAP-TLS применяет TLS для взаимной сертификатной аутентификации, защищённого согласования криптографических алгоритмов, обмена и вывода ключей. При полном взаимном обмене проверка пути отвечает на вопрос, завершается ли предъявленная цепочка доверенным якорем в текущей политике проверяющей стороны. CertificateVerify показывает, что endpoint может подписать транскрипт закрытым ключом. Finished показывает, что обе стороны дошли до одного защищённого транскрипта и согласованных секретов.

Именно потому, что эти факты сильны, им нельзя приписывать чужую работу. Subject или SAN может предоставить удостоверенный идентификатор для политики. Он не содержит живого состояния switch port, текущей доступности VLAN, результата установки ACL, целостности пути через AAA proxy или достижимости приложения.

Способ менялся, но граница сохранилась. RFC 8996 исключил TLS 1.0 и 1.1. RFC 9190 определил применение TLS 1.3, изменив handshake и key schedule, при этом RFC 5216 остался основой для согласованных старых версий. RFC 9965 добавил механизм provisioning вокруг eap.arpa. Ни одно изменение не превратило аутентификацию в измеритель всей услуги.

Раздел об авторизации в RFC 9190 относится к EAP-TLS в целом. Авторизация и accounting должны использовать удостоверенные данные — сертификатную или PSK-идентичность, provisioned state возобновления, — а не одну незащищённую EAP-Response/Identity. Сервер может учитывать сведения об окружающем соединении: authenticator, MAC- или IP-адрес, порт, SSID.

Это не заплатка после аутентификации. Это корректная архитектура: аутентификация поставляет данные для решения, но не поглощает само решение и его исполнение.

EAP не обещает синхронного разрешения

RFC 3748 отдельно рассматривает синхронизацию результата аутентификации и синхронизацию авторизации. EAP-сервер может не видеть решение, принятое AAA proxy. AAA-сервер может дождаться успешной проверки личности, а затем отказать в разрешении. Backend может разрешить доступ, когда authenticator временно не способен предоставить нужную услугу.

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

RFC 4137 описывает state machines EAP peer и authenticator и сигналы в lower layer. Выход автомата остаётся событием интерфейса. Он сообщает вывод EAP, а не результат скрытой проверки switching fabric, выдачи адреса и приложения.

Поэтому EAP-Success ценен только в своём диапазоне. Он не бессмыслен, но и не тождествен доступу в сеть. Результат EAP ещё должен встретиться с политикой AAA и действием нижнего уровня. Без этого различия «сертификат принят», «аутентификация прошла», «доступ разрешён», «порт открыт» и «сервис работает» становятся одним счётчиком без определённого владельца.

Ключевой материал появляется раньше полного права

EAP-TLS выводит Master Session Key и Extended Master Session Key. Их свежесть и привязка важны, однако RFC 5247 явно делит процесс на фазы. EAP method создаёт материал между peer и server. AAA доставляет нужную часть authenticator. Secure association protocol доказывает владение и строит временные ключи.

Далее сформулировано принципиальное ограничение: доказательство владения ключевым материалом не обязательно доказывает авторизацию на владение им. Four-way handshake способен показать, что peer и authenticator имеют общий EAP-derived material. Сам по себе он не показывает, что backend разрешил именно этому authenticator получить материал для этой сессии.

RFC 4962 выделяет авторизацию peer и authenticator как отдельное требование. RFC 4017 раздельно перечисляет взаимную аутентификацию, стойкость ключей и авторизацию для WLAN. RFC 5295 ограничивает корневые ключи из EMSK назначением и областью, а не трактует владение как универсальное разрешение.

Урок выходит за пределы Wi-Fi. Криптография подтверждает, что компонент располагает ключом. Без отдельной политики и provenance она не подтверждает право получить ключ для этого субъекта, услуги, места и времени. Случайные байты не кодируют административный мандат.

Access-Accept должен быть выполнен конкретным NAS

В распространённой pass-through схеме NAS переносит EAP между peer и backend RADIUS. RFC 3579 различает RADIUS Access-Accept и Access-Reject и инкапсулированные сообщения EAP. Reject требует отказа. Accept завершает фазу аутентификации и может нести авторизации, которые должна применить эта точка доступа.

Точка доступа не является принтером ответа. RFC 3579 требует, чтобы NAS, не способный предложить запрошенную услугу, рассматривал соответствующий Access-Accept как Access-Reject. RFC 3580 предупреждает о возможном противоречии между видом RADIUS packet и вложенным EAP Success или Failure; решение доступа основывается на RADIUS result, а не слепо на внутреннем пакете.

Вернувшийся role, VLAN, filter или session limit — это инструкция политики, успешность которой наблюдают там, где она исполняется. Лог backend доказывает отправку. Он не доказывает, что NAS распознал все attributes, располагал локальным ресурсом, установил точную политику и перевёл controlled port в открытое состояние.

Отчёт NAS тоже не является последней точкой. После открытия порта может отказать DHCP. После выдачи адреса может не работать DNS. Пробный пакет может проходить, а целевое приложение блокироваться. Каждая следующая граница получает собственную квитанцию.

Почему данные о сети имеют другой источник

RFC 6677 рассматривает pass-through authenticator, способный описать peer одну сеть, а AAA infrastructure — другую: проблему lying NAS или lying provider. Channel binding позволяет peer и server сравнить свои представления о существенных свойствах сети через защищённый канал.

Само существование механизма показывает: сертификат клиента не удостоверяет всё, что сообщает сеть доступа. SSID, port, visited provider, lower-layer type и свойства услуги происходят из отдельных источников. Они подходят для политики только после проверки provenance и согласованности.

Channel binding при этом не является квитанцией доставки. Он способен подтвердить определённый контекст до того, как клиент примет последствия подключения. Он не показывает, что выбранная VLAN впоследствии переслала трафик, firewall пропустил приложение и услуга продолжала работать через пять минут.

RFC 7542 уточняет обращение с Network Access Identifier. RFC 9427 обновляет TLS 1.3 для TLS-based EAP methods. Они улучшают идентификаторы и переходы протокола, но не объединяют независимые источники в одно доказательство.

Возобновление не замораживает полномочия

TLS 1.3 resumption сокращает число round trips и может не повторять сертификатную работу полностью. RFC 9190 считает принятое возобновление аутентифицированным и безопасно связанным с предыдущей аутентификацией либо resumption. Одновременно он требует не давать возобновлённой сессии больше привилегий, чем было задумано для исходной.

У системы несколько часов. Ticket может ещё проходить криптографическую проверку, когда сертификат отозван, устройство получило другую роль, сотрудник утратил доступ, NAS перемещён, политика SSID изменена или VLAN снята. Certificate lifetime, revocation freshness, ticket lifetime, authorization lifetime, port session и application outcome не являются одним сроком.

RFC 9190 усиливает revocation processing для TLS 1.3 и обсуждает OCSP stapling, поскольку до завершения аутентификации у peer может не быть общего соединения. Этот круг показывает практический предел bootstrap: часть evidence приходится подготовить до сети. Успешный bootstrap всё ещё не является доказательством того, что сеть предоставила потом.

Квитанция для каждого перехода

В certificate receipt нужны trust anchor, точные хеши leaf и chain, проверенное имя, validity window, способ и результат revocation. TLS receipt хранит negotiated version и suite, результаты CertificateVerify и Finished, безопасный идентификатор сессии, но не секреты.

EAP receipt хранит method, protected result, идентификаторы exported keys и EAP Success либо Failure. AAA receipt связывает authenticated peer identity, NAS identity, port и network context, policy version, Accept или Reject и точные authorization attributes. Key-transport receipt отвечает, какой authenticator имел право получить какой scoped material.

Enforcement receipt создаётся на NAS: распознаны ли attributes, разрешены ли role и VLAN, установлена ли ACL, завершена ли secure association, открыт ли controlled port. Service receipt появляется позже: address assignment, ARP или neighbour state, DNS, route, первый успешный application exchange и причина ошибки.

Отрицательные результаты необходимо сохранять без косметики. «Сертификат действителен; авторизация отклонена» не противоречие. «Access-Accept получен; услуга недоступна» не повод скрыть запись. «Порт открыт; приложение не работает» не опровергает аутентификацию. Такое разделение быстрее ведёт к ремонту, потому что оставляет видимой точку отказа.

Источники

  1. RFC 5216
  2. RFC 5216 в IETF Datatracker
  3. Статус RFC 5216
  4. История RFC 5216
  5. Errata RFC 5216
  6. RFC 9190
  7. RFC 3748
  8. RFC 5247
  9. RFC 4017
  10. RFC 6677
  11. RFC 8996
  12. RFC 9965
  13. RFC 7542
  14. RFC 3579
  15. RFC 3580
  16. RFC 4137
  17. RFC 4962
  18. RFC 5295
  19. RFC 9427
  20. Heng Lu — Running-Code Primacy
  21. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption