Кратко

  • Узел может хранить ключ EAP в пределах локального срока, когда аутентификатор уже потерял соответствующую запись из-за перезапуска или вытеснения.
  • RFC 5247 рекомендует защищённую ресинхронизацию; если общего ключа для защиты ремонта больше нет, полномочия должна восстановить новая аутентификация.

Девять оставшихся минут ничего не говорили о соседе

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

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

RFC 5247 не допускает такого сокращения. В требованиях к протоколу защищённой ассоциации сказано, что peer или authenticator может перезапуститься либо освободить ресурсы и удалить часть или весь кэш. Поэтому согласование срока жизни не гарантирует синхронность. Peer иногда узнаёт об отсутствии удалённой записи лишь при попытке её использовать.

Срок ограничивает допустимое использование существующего объекта. Он не арендует память на другой стороне.

Сохранённый результат не заменяет новый стык

Архитектура EAP делит путь на несколько действий. Метод между peer и EAP-сервером может выдать MSK, EMSK и идентификаторы. Обмен AAA доставляет материал и параметры авторизации аутентификатору. Затем peer и authenticator напрямую выполняют протокол защищённой ассоциации: выбирают контекст, доказывают владение и создают временные сеансовые ключи.

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

Успех старой аутентификации — исторический факт. Защищённое доказательство совместного владения — факт настоящего времени. Ни один таймер не превращает первое во второе.

Имя координирует выбор, а не выдаёт полномочие

У одной пары сторон может находиться несколько ключей одного типа. RFC 5247 требует явно называть ключ, применяемый в доказательстве владения. Иначе обе стороны способны выбрать существующие, но разные поколения.

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

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

Команда восстановления тоже нуждается в основании

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

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

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

Это не просто медленный fallback. Это правильное направление доверия: подтверждённое полномочие создаёт состояние; просьба создать состояние не порождает полномочие.

Состояние может совпасть, а область — нет

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

Ключ для одного аутентификатора, порта, набора услуг или профиля трафика не становится универсальным из-за оставшегося времени. При перемещении маршрут AAA способен выбрать другой EAP-сервер. Серверы одного realm могут проверять одинаковые credentials, не разделяя всё постоянное состояние.

Поэтому неудачное возобновление совместимо с потерей, неверным выбором, несовпадением области, изменением backend или новой политикой. Без дополнительного наблюдения ни одна причина не заслуживает статуса факта.

Не превращать miss в обвинение пользователя

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

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

Если данных недостаточно, причина остаётся неизвестной. Стандарт перечисляет допустимые механизмы расхождения, но не сообщает, что произошло в конкретном продукте или сети.

Испытание должно удалить ровно одну копию

Одновременный перезапуск обеих сторон скрывает ключевую проблему. Нужны четыре режима: запись есть у обеих; только у peer; только у authenticator; ни у кого. Для каждого проверяют ограниченное число попыток, переход к полной аутентификации, выпуск свежих TSK и отсутствие незаметного возврата старых ключей.

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

Поэтому важна не только ёмкость кэша. Важна пропускная способность безопасного восстановления misses вплоть до реально работающего сервиса.

Sources