Кратко

  • RFC 5296 сокращает повторную EAP-аутентификацию до одного раунда, но серверный replay commit, защищённый Finish, AAA-доставка, установка rMSK и нижнеуровневый доступ остаются разными состояниями.
  • Сквозная квитанция связывает SEQ и окно с одной генерацией и одним аутентификатором, а затем с TSK и реальным решением доступа.

Быстрый путь не является общей транзакцией

ERP позволяет пиру с действующим материалом не повторять полный метод EAP у нового аутентификатора. Initiate проходит к ER-серверу, Finish возвращается за один раунд.

Аутентификатор ретранслирует ERP, сервер проверяет rIK и свежесть, AAA несёт rMSK, пир выводит то же значение, а нижний уровень создаёт TSK. Каждый участник способен завершить свой шаг, пока следующий ещё не начался.

Сервер первым меняет долговечное состояние

Initiate содержит 16-битный SEQ, один keyName-NAI, криптонабор и тег. Для новой rRK SEQ начинается с нуля. Сервер проверяет ожидаемое значение или неиспользованную позицию окна, затем набор и целостность.

После принятия он выводит rMSK. Finish повторяет SEQ, а сервер продвигает ожидание или окно. Потеря ответа не обязана откатывать изменение. Нужны состояние до, границы окна, проверка использования, решение, время и состояние после.

Identifier отличает повтор транспорта

Ретрансляция сохраняет EAP Identifier, новый Initiate выбирает другой. Finish должен совпасть с открытым запросом. Identifier связывает обмен, SEQ предотвращает replay и участвует в ключе.

Единый внутренний request ID теряет эту разницу. Рекомендованная очистка состояния аутентификатора через 300 секунд также не синхронизирует пир и сервер.

Finish подтверждает только диалог с пиром

Пир проверяет ожидаемый SEQ и целостность, затем выводит rMSK. После этого протокол нижней ассоциации лишь готов к запуску.

Finish не является подтверждением AAA, установки или TSK. Он не доказывает, что аутентификатор выбрал ту же генерацию и начал пропускать трафик. Создание и проверка Finish, AAA, установка, старт и итог TSK, access verdict должны быть раздельны.

Один rMSK — один аутентификатор

rMSK выводится из rRK, метки, SEQ и длины, не разделяется между аутентификаторами и не живёт дольше rRK. После нового корня будущие rMSK идут от него, но старые выданные могут работать до срока.

При bootstrap нижний уровень может игнорировать полученный rMSK из-за уже действующих TSK от прежнего MSK или создать новые. Доставка не определяет выбор.

Конкурентность создаёт окно

Пир может вести ERP через несколько аутентификаторов одновременно, и сообщения приходят не по порядку. Сервер допускает неиспользованные SEQ в локальном окне.

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

Непроверяемая ошибка не называет причину

Failure-Finish защищается при наличии rIK и может предложить другие наборы. При смене PRF перестраивается цепь ключей.

Сбой replay или integrity может быть подделкой или несовместимостью наборов. Пир не знает и продолжает ретрансляцию. Это неопределённость, а не доказанная атака.

Действующий root важнее найденного контекста

RFC 6696 обратно совместимо заменил RFC 5296 и уточнил проверку текущего владения валидным root-материалом при implicit bootstrap. Старый контекст не даёт права отвечать.

Но текущее владение — лишь допуск к следующему шагу. Поколение нужно связать с SEQ, rMSK, адресатом и результатом.

Квитанция цепочки

Свяжите rRK и срок; keyName-NAI и домен; Identifier; SEQ и окно; набор и integrity; принятие и переход счётчика; rMSK и единственный аутентификатор; Finish; AAA; получение и установку; вывод пира; выбранный MSK/rMSK; TSK; доступ; fallback; повторы; channel binding. Секретов в записи быть не должно.

Sources