Кратко

  • EAP Provisioning Identifier из RFC 9965 — публичный NAI, сообщающий о желаемом способе подготовки. Он не подтверждает личность устройства, право владения или право на обычный доступ.
  • Принятый узел остаётся недоверенным. Разрешается только ожидаемый трафик; отдельно ограничиваются время, объём данных, сервисы, попытки и число параллельных сеансов, а сами узлы изолируются друг от друга.
  • Квитанция закрытия канала подготовки должна связать запрос, реально применённую политику и подтверждение удаления либо истечения. Это редакционное предложение Daniel Kade, а не требование IETF.

Общий пароль, который паролем не является

Обычная аутентификация предполагает, что у устройства уже есть пароль, сертификат или иной индивидуальный материал. При первом включении возможна обратная зависимость: чтобы получить такой материал, устройству нужна сеть. RFC 9965 решает задачу не выдачей мнимого доверия, а формализованным запросом на ограниченную подготовку.

EAP Provisioning Identifier, или EPI, использует формат NAI из RFC 7542. Realm eap.arpa и пользовательская часть указывают требуемый механизм. В реестре IANA находятся @noob.eap.arpa для EAP-NOOB и portal@tls.eap.arpa для ограниченного портального доступа через EAP-TLS.

Значение можно заранее встроить в множество устройств именно потому, что оно известно всем. Следовательно, его предъявление не доказывает редкого знания. Оно не связывает узел с покупателем, текущим владельцем, строкой инвентаря или разрешённой производственной ролью. Корректная строка — это корректно сформулированная просьба.

RFC 9965 требует считать узел с EPI недоверенным и не заслуживающим доверия. Сеть вправе отказать по собственной политике или из-за нехватки ресурсов. Если просьба принята, узел помещается в ограниченную сеть, а не получает неограниченный доступ.

Первый успешный результат поэтому означает только открытие узкой процедуры. Второй успех — например, выпуск сертификата — относится к сервису подготовки. Ни один из них сам по себе не доказывает, что коммутатор, точка доступа или шлюз удалили временную ACL.

Так возникает опасное послесловие к удачной операции: постоянная учётная информация уже создана, но рядом с ней продолжает жить более слабый вход. Его удаление нельзя считать ночной уборкой. Время окончания входит в само содержание временной привилегии.

Особое имя не назначает внешнего распорядителя

Запись похожа на доменное имя, однако RFC 9965 различает realm NAI eap.arpa и DNS-имя eap.arpa.. IANA включает его в реестр доменов специального назначения, но оно не предназначено для обычного DNS или протоколов вне EAP. DNS-запрос должен получить NXDOMAIN.

Это ограничение удерживает решение внутри принимающей сети. Сервер не должен воспринимать публичный realm как указатель на удалённый центр доверия. Он сам определяет, знает ли EPI, поддерживает ли связанную методику и какую минимальную поверхность откроет.

Ошибки тоже обрабатываются узко. Неверно оформленный EPI приводит к EAP Failure. Неизвестный идентификатор, неподдерживаемый метод или метод, не соответствующий EPI, получает EAP Nak типа ноль. С учётными данными подготовки не допускается свободный торг о другом EAP-методе.

Эта строгость обеспечивает совместимость, а не право устройства. IETF определяет общий механизм, IANA ведёт соответствия, оператор контролирует край сети, владелец актива решает, кому предстоит окончательное зачисление. Запись в реестре не может заменить локальное решение на конкретном порту.

Поэтому единицей аудита должен быть короткий сеанс: какой EPI пришёл, в каком контексте доступа, какая версия политики его приняла, что установили средства контроля, чем всё закончилось и когда исключение исчезло.

Ограничение описывается разрешениями

Название роли «onboarding» ничего не говорит о фактическом маршруте пакетов. RFC 9965 требует разрешать только ожидаемый трафик и блокировать остальное. Запретить несколько известных плохих направлений недостаточно: незамеченный вспомогательный сервис, включая DNS, может стать транспортным каналом.

Доказательство должно доходить до точки применения. Нужны идентификатор и версия Filter-Id, VLAN, ACL, динамической роли или политики контроллера; перечень устройств, применивших её; разрешённые адресаты, протоколы и порты; обоснование вспомогательного доступа к времени, именам или проверке сертификатов; явное действие по умолчанию.

RFC перечисляет несколько независимых бюджетов:

  • Нормальная подготовка занимает секунды или десятки секунд; долгий сеанс может указывать на сбой.
  • Объём данных ограничивается, поскольку большие загрузки обычно не нужны.
  • Доступно лишь небольшое число необходимых сервисов.
  • Попытки ограничиваются по частоте; нарушителя можно временно или постоянно блокировать.
  • Общее число одновременно подготавливаемых узлов имеет предел.
  • Узлы в ограниченной сети не должны общаться друг с другом.

Время ограничивает пребывание, байты — использование как канала, список разрешений — достижимую поверхность, частота и параллельность — нагрузку на RADIUS, DHCP, выдачу сертификатов и поддержку. Изоляция не даёт неизвестным устройствам атаковать соседей в том же временном сегменте.

Один бюджет не заменяет другой. Десять секунд с общим выходом остаются широким доступом. Точная ACL без срока становится постоянным обходом. Небольшая очередь не мешает одноранговым атакам.

Упомянутый в RFC атрибут RADIUS Filter-Id — один из способов привязать политику. Можно использовать VLAN, ACL или объект контроллера. Главное — восстановить по записи реальное содержимое и ревизию. Одинаковое имя политики до и после расширения списка разрешений создаёт ложную непрерывность.

Повторные сеансы также не должны склеивать множество коротких сроков в один длинный. До появления индивидуальной личности частоту можно связывать с подходящим, недолговечным контекстом порта или радиодоступа. Этот контекст служит защите ресурсов, но не превращается в доказательство владения.

Неизвестен узел, но не источник конфигурации

Слово «неаутентифицированный» относится к подготавливаемому узлу. Каждый метод под eap.arpa должен определить способ аутентификации сервера: внутри EAP или позже, например через HTTPS. Сам узел всё равно обязан считать локальную сеть недоверенной.

В portal@tls.eap.arpa допускается EAP-TLS без аутентификации пира, однако сервер должен быть подтверждён, например сертификатом. Общедоступный предварительный ключ не даст такой гарантии. Сеть принимает от неизвестного устройства малый поток, а устройство не должно принимать свою будущую долгосрочную конфигурацию от неизвестного собеседника.

RFC 8952 полезно разделяет роли портальной системы. Provisioning Service сообщает URI, API описывает состояние ограничений, пользовательский портал исполняет условия, Enforcement Device пропускает или отбрасывает пакеты. Они могут быть размещены рядом, но создают разные доказательства.

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

Выдача и допуск — не один переход

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

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

Прозрачная последовательность сначала завершает EPI-сеанс. Затем устройство начинает обычную аутентификацию с новым материалом. Текущая политика авторизации принимает отдельное решение для уже аутентифицированной личности. Для пользователя переход может быть незаметен, но источники полномочий различны.

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

Именно здесь тема отличается от ранее опубликованного разбора RFC 9966. TLS-POK подтверждает ограниченное отношение знания Bootstrap Key, но не законность его происхождения и хранения. Этот материал не повторяет цепочку владения ключом; он рассматривает жизненный цикл сети вокруг публичного EPI. Доказательство ключа не удаляет ACL, а удаление ACL не доказывает хранение ключа.

Квитанция закрытия

Локальная квитанция может объединить семь групп:

  1. Запрос: точный EPI, метод EAP, время, Authenticator или NAS, интерфейс и короткоживущий идентификатор сеанса.
  2. Решение: принятие либо отказ, версия политики, состояние ёмкости, класс причины и ответственный сервис.
  3. Применение: фактически установленный фильтр, сегмент, роль или ACL, их версия и точки enforcement, список разрешений, default-deny и изоляция пиров.
  4. Бюджеты: начало, жёсткий срок, байты, сервисы, число попыток, rate-limit и занятая параллельная ёмкость.
  5. Подлинность сервера: метод проверки, ссылка на сертификат или trust anchor, результат и строго очерченное исключение.
  6. Итог: успех или точный класс отказа; при выпуске учётного материала — защищённая ссылка и предполагаемый срок, но не секреты.
  7. Закрытие: время и причина удаления или истечения, наблюдение точки применения, обработка остаточных потоков, новый аутентифицированный сеанс и сверка сиротских состояний.

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

«Квитанция закрытия канала подготовки» — редакционный термин Daniel Kade. RFC 9965 его не вводит. Это не сертификат IETF, не сетевая учётная запись и не объект API статьи. Предложение лишь делает локальное окончание исключения проверяемым.

Нулевой TTL и удалённое правило — разные факты

Срок может закончиться в базе контроллера, а ACL остаться на коммутаторе. Команда удаления может попасть в старую генерацию или быть отмечена выполненной при отсутствии связи. И наоборот, устройство способно закрыть путь раньше, чем оркестратор обновит экран.

Нужно хранить плановый срок, действие управляющей плоскости и наблюдение плоскости данных. Разница во времени — самостоятельный сигнал. Автоматическое истечение и подтверждённое удаление тоже не следует объединять.

При сбое канал закрывается так же строго, как при успехе. Недоступный портал не оправдывает общий Интернет. Медленная выдача сертификата не даёт права молча продлевать время. Ошибка конфигурации не оставляет пир в вечном ожидании.

Сверка сопоставляет три состояния: что хотела разрешить политика, что реально применялось во время сеанса и что осталось после. Несовпадение нельзя растворять в зелёной сводной оценке — именно оно требует разбора.

Так работает Policy Mirror Хэна Лу: формальное правило показывает предполагаемую власть, исполняемая конфигурация — практическую. Управляемость возникает в сравнении, когда исключение оставляет свидетельство собственного прекращения.

Пределы и источники

Источники подтверждают устройство стандартов, реестры и заявленные риски. Они не измеряют распространённость RFC 9965, не называют внедрившего его оператора и не доказывают инцидент. Средства enforcement, сроки и границы конфиденциальности будут различаться.

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