Кратко
- FRID — созданный сервером псевдоним NAI для поиска существующего контекста EAP-IKEv2. Совпадение с записью не доказывает, что предъявитель владеет ключами этого контекста.
- Fast reconnect завершается только после проверки защищённых сообщений 3 и 4 старым контекстом, обмена новыми SPI и nonce и вывода свежих MSK/EMSK. Авторизация сети, установка ключей и работа сервиса остаются отдельными событиями.
Во время предыдущей сессии сервер отправил новый псевдоним. В следующей попытке устройство предъявляет старый. Если база хранит только «последнее выданное», оператор видит неизвестную идентичность. Если база хранит последнее подтверждённое состояние, попытку ещё можно связать с рабочим контекстом.
RFC 5106 задаёт именно такую осторожную модель. Экспериментальный метод EAP-IKEv2 использует механизмы IKEv2 для взаимной аутентификации и создания сессионных ключей. Быстрое переподключение обязательно реализовать, но применять его необязательно; решение остаётся за локальной политикой.
Полный обмен сначала создаёт доверенный контекст. EAP-сервер выступает IKEv2 initiator, пир — responder. Они согласуют алгоритмы, обмениваются nonce и Diffie-Hellman, проверяют защищённые ID и AUTH. Только успешный результат позволяет EAP-Success и экспорт MSK/EMSK.
В защищённом потоке сервер может передать Next Fast-ID. NFID содержит Fast-Reconnect-ID в формате NAI. Username заменён псевдонимом, realm остаётся для маршрутизации AAA. Сервер сохраняет связь с постоянной идентичностью и контекстом.
FRID — указатель, а не переносимое доказательство. Случайная свежая часть помогает уникальности, но человек, узнавший строку, не получает старые ключи. Положительный lookup отвечает только на вопрос, какой набор состояния попробовать.
Следующая попытка может попасть не на тот же сервер. RFC не гарантирует закрепление и предлагает домашним серверам общий механизм разрешения псевдонимов. Без него принимающий узел может запросить постоянную идентичность. Неизвестный FRID может означать отсутствие репликации или удалённый контекст, а не подделку.
Пир вправе предъявить FRID только после получения его в успешном предыдущем обмене. EAP-Response/Identity обязателен. Найдя контекст, сервер может выбрать fast reconnect или полный обмен. Пир обязан обработать полный message 3 даже после запроса быстрого пути.
Поэтому frid_presented, context_mapped и fast_path_selected нельзя записывать одним состоянием «authenticated». Первые два относятся к адресации состояния, третье — к политике. Доказательство владения ключами начинается дальше.
Сообщения 3 и 4 fast reconnect защищаются ключами предыдущего успешного контекста. Сервер выбирает новый ненулевой SPI в proposal и свежий Ni. Опциональный KEi тоже должен быть свежим. Пир расшифровывает и проверяет message 3, формирует собственный новый SPI и Nr, затем защищает message 4.
Сервер расшифровывает и проверяет ответ. Только корректный message 4 делает run успешным и позволяет отправить EAP-Success. База могла вернуть правильный идентификатор, а проверка всё равно завершиться неудачей из-за разной генерации ключей или нарушенной целостности.
После успеха создаётся новый контекст. SKEYSEED использует старый SK_d, Ni, Nr и, если обменивались новыми DH-значениями, новый общий секрет. Остальные ключи EAP-IKEv2 пересчитываются. Из KEYMAT первые 64 октета становятся MSK, вторые 64 — EMSK. До успешного завершения их формировать нельзя.
Новый Session-ID включает тип метода и текущие Ni/Nr. Peer-ID и Server-ID берутся из полного обмена, создавшего исходный контекст. FRID называет запись, Peer-ID/Server-ID — ранее аутентифицированные стороны, Session-ID — свежий run. Это разные ключи аудита.
Особенно важна смена FRID. Сервер может послать новый NFID, но пир не успеет сохранить его из-за сбоя. Поэтому серверу следует держать как последний использованный, так и последний выданный FRID. При неудачной аутентификации он не должен затирать значение последнего успешного обмена.
Правило задаёт границу commit. issued не равно durably stored, а самый новый timestamp не равен согласованному состоянию. Если неподтверждённое обновление становится единственной истиной, один потерянный ответ разрушает путь восстановления.
Повтор старого message 3 после успешного reconnect должен провалиться, потому что ключи уже сменились. Но до commit повтор пакета может быть допустимой retransmission. Чтобы различать случаи, нужны context generation, SPI, nonce digests, результаты проверки и отметка успешного перехода. Один FRID недостаточен.
Псевдоним обеспечивает ограниченную конфиденциальность: username скрыт, realm виден. Нельзя превращать FRID в долговечный трекер в логах. Периодический digest вместе с generation позволяет корреляцию, не раскрывая исходную строку всем системам наблюдения.
EAP-Success подтверждает завершение метода. RFC 5247 рассматривает ключи в более широкой архитектуре. AAA отдельно разрешает услугу, authenticator получает и устанавливает материал, lower layer открывается, затем трафик и сервис дают свои наблюдения.
RFC 5106 не поддерживает channel binding. Поэтому успешный метод не подтверждает все свойства нижележащей сети доступа. Надпись «подключено к правильной сети» требует дополнительного источника доказательств.
Наконец, профиль 2008 года историчен. MODP 1024, 3DES и преобразования эпохи SHA-1 были частью тогдашней совместимости. Соответствие документу не означает приемлемость сегодня. Нужны отдельные записи о выбранном suite и версии актуальной политики.
Операционный журнал связывает digest FRID, realm, сервер выдачи и приёма, mapping, generation, выбор fast/full, новые SPI, Ni/Nr digests, DH group, проверки messages 3/4, Session-ID, EAP result и key handles. Сырые ключи не копируются в телеметрию.
Следом добавляются AAA decision, receipt установки, первый защищённый пакет и service probe. Тогда сигнал точно называет разрыв: неизвестный псевдоним, разные поколения, integrity failure, nonce reuse, успех без экспорта, авторизация без установки или установка без трафика.
Быстрое переподключение экономит полный обмен, но не отменяет подтверждение общего состояния. Сохранять последнюю успешную реальность важнее, чем безусловно верить самому новому выданному идентификатору.
Источники
- https://www.rfc-editor.org/rfc/rfc5106.html
- https://www.rfc-editor.org/rfc/rfc5106.txt
- https://www.rfc-editor.org/info/rfc5106
- https://www.rfc-editor.org/errata/rfc5106
- https://datatracker.ietf.org/doc/rfc5106/
- https://datatracker.ietf.org/doc/rfc5106/history/
- https://www.rfc-editor.org/rfc/rfc3748.html
- https://www.rfc-editor.org/rfc/rfc4306.html
- https://www.rfc-editor.org/rfc/rfc4307.html
- https://www.rfc-editor.org/rfc/rfc4282.html
- https://www.rfc-editor.org/rfc/rfc4962.html
- https://www.rfc-editor.org/rfc/rfc5247.html
- https://www.rfc-editor.org/rfc/rfc5296.html
- https://www.rfc-editor.org/rfc/rfc7296.html
- https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
