Кратко

  • RFC 5422 рекомендует не открывать сеть после Server-Unauthenticated Provisioning; в режиме с аутентификацией сервера допуск возможен по его политике.
  • Подтверждение Tunnel PAC передаёт заявление узла об обработке и сохранении; оно не доказывает последующую аутентификацию или допуск.

Первичная настройка заканчивается раньше допуска

Устройство может прийти без общего секрета, доверенного корневого сертификата сервера или Protected Access Credential. RFC 5422 описывает динамическую выдачу таких данных через EAP-FAST. Важен не только факт успешного обмена, но и его значение: подготовлено ли устройство или ему уже разрешён сетевой доступ? Документ разводит эти результаты.

EAP-FAST состоит из первой фазы TLS и внутренней фазы EAP. RFC 5422 различает настройку с аутентификацией сервера и без неё. В первом случае узел проверяет сервер во время TLS-рукопожатия и заранее нуждается в материале доверия. Во втором используется анонимный TLS-туннель на основе Diffie–Hellman: он упрощает первоначальную настройку, но не устанавливает личность сервера на первой фазе.

Анонимная первая фаза не отменяет аутентификацию. Узел и сервер должны завершить внутри туннеля метод EAP с взаимной аутентификацией и выработкой ключей. Затем узел проверяет Crypto-Binding TLV, чтобы связать внутренний обмен с целостностью TLS-туннеля и обнаружить активное вмешательство. Редакция 2009 года требует, чтобы реализация этого режима поддерживала EAP-FAST-MSCHAPv2 как внутренний метод аутентификации. Если смотреть только на внутренний успех, можно потерять связь с внешним каналом. (RFC 5422 §§2, 3.2–3.2.3, 6.1.2; RFC 4851)

После внутренней аутентификации и успешной проверки привязки сервер может выдать Tunnel PAC, включая PAC-Key и PAC-Opaque, либо доверенные корневые сертификаты. Tunnel PAC помогает установить будущий EAP-FAST-туннель, но сам по себе не даёт права использовать сеть.

Узел отправляет PAC-Acknowledgement, сообщая результат обработки и сохранения нового Tunnel PAC. Это подтверждение не применяется к другим типам PAC. Сервер получает сообщение самого узла, а не доказательство последующей успешной аутентификации, допуска политикой или доставки трафика приложению. (RFC 5422 §§3.2, 4.1.4, 4.2.5)

RFC 5422 говорит прямо: после Server-Unauthenticated Provisioning сетевой доступ НЕ СЛЕДУЕТ предоставлять, поскольку этот разговор предназначен только для настройки. Политика узла может разорвать соединение и начать новый EAP-FAST-обмен с только что полученными данными. Для Server-Authenticated Provisioning сервер МОЖЕТ предоставить доступ после успешной настройки. Поэтому слово «успех» не объединяет эти разные решения. (RFC 5422 §3.5)

У режимов разные издержки. Проверка сервера лучше защищает от посредника, но требует заранее установленного доверия. Анонимный режим облегчает первоначальную настройку без участия пользователя, однако RFC 5422 отмечает повышенный риск офлайн-подбора для паролезависимого внутреннего обмена. Документ также рекомендует ограничивать онлайн-попытки и поощряет сужать места или условия использования анонимного режима. Это положения Informational RFC 2009 года, а не статистика современного применения. (RFC 5422 §§6.1–6.3)

Рабочий журнал должен раздельно хранить режим настройки, результат внутренней взаимной аутентификации и Crypto-Binding, тип и срок действия выданных данных, подтверждение Tunnel PAC, последующую аутентификацию и решение о доступе. Если за выдачу и допуск отвечают разные команды, им нужны общий идентификатор сеанса и владелец расследования пропущенного второго обмена. Успех начального обмена этот пробел не закрывает.

Успешный внутренний обмен всё ещё может закончиться отказом

Раздел 3.5 оставляет решение о допуске политике сервера даже после успешной настройки. В режиме Server-Authenticated сервер может открыть доступ после аутентификации узла и выдачи Tunnel PAC. В режиме Server-Unauthenticated доступ в конце обмена НЕ СЛЕДУЕТ предоставлять: этот разговор предназначен только для настройки. Передача учётных данных поэтому не даёт одинакового результата авторизации в обоих режимах.

Успешный Result TLV не решает вопрос о доступе. Внутренний метод может завершиться успешно, а сервер всё равно сочтёт политику невыполненной и закончит обмен сообщением EAP Failure. Если обмен не предназначен для открытия сети, RFC 5422 запрещает предоставлять доступ и передавать ключи сессии Network Access Server. Панель, которая учитывает только успех внутренней аутентификации, может показать зелёный статус, хотя сеть обоснованно отказала в допуске. Наблюдение должно охватывать конечный EAP-результат и передачу ключа, а не останавливаться на первом признаке успеха. (RFC 5422 §3.5; RFC 4851 §4.2.2)

Подтверждение относится лишь к одному этапу жизни credential

Tunnel PAC состоит из разных элементов. PAC-Key — секрет длиной 32 октета для создания туннеля фазы 1. PAC-Opaque, специфичный для выдавшего его сервера, предъявляется этому серверу при следующей аутентификации. PAC-Info может сообщать издателя и срок действия. RFC 4851 требует защищать PAC-Key; RFC 5422 возлагает на узел и сервер ответственность за безопасное хранение. После выдачи остаются задачи по защите, истечению срока и обновлению credential.

PAC-Acknowledgement имеет узкий смысл: узел отправляет его для нового Tunnel PAC и сообщает результат обработки и сохранения — успех или неудачу. Успех фиксирует заявление узла в данный момент. Он не доказывает, что позднее удастся построить туннель, что секрет сохранится в безопасности или что политика разрешит доступ. Только следующий обмен EAP-FAST проверяет credential в новом контексте аутентификации. Даже его успех ещё не доказывает доступность приложения. (RFC 5422 §§4.2.2–4.2.5, 6.8; RFC 4851 §3.2.2)

Отказ может нарушить связь

Разделение решений имеет цену для доступности. RFC 5422 отмечает, что EAP Failure после отказа в доступе может вызвать полную диссоциацию устройств 802.11. Узел или сервер могут попробовать TLS-перенеговоры, чтобы продолжить с новыми учётными данными без полного перезапуска; любая сторона вправе отказать в запросе. Обычная политика доступа применяется лишь после успешной последующей аутентификации. Поэтому стоит измерять возврат устройств, отказы и восстановление через перезапуск или TLS-перенеговоры. Иначе намеренный отказ будет выглядеть как ошибка настройки, а число успешных выдач скроет узлы, так и не получившие доступ. (RFC 5422 §3.5)

Источники