Кратко

  • RFC 9867 позволяет примешивать PPK в IKEv2 через IKE_INTERMEDIATE и CREATE_CHILD_SA, в том числе применять свежий PPK при создании или смене ключей Child SA либо IKE SA.
  • Ответ на CREATE_CHILD_SA может не содержать идентификатор PPK, но обычная обработка IKEv2 всё равно создаст SA. Если такой откат нарушает обязательную политику инициатора, он может немедленно удалить новорожденную ассоциацию.
  • Для каждой SA нужен документ о примешивании PPK, отдельно фиксирующий выбор, подтверждение, авторизацию, создание, принятие, использование и удаление. Это редакционное предложение Daniel Kade, а не требование RFC или IETF.

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

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

В одной связи сосуществуют разные родословные ключей

IKEv2 не создаёт один неизменный «туннель». Он устанавливает IKE SA, аутентифицирует стороны, создаёт Child SA и позволяет независимо менять ключи обоих типов. Фраза «туннель использует PPK» не сообщает, о какой SA, каком обмене и какой выработке идёт речь.

RFC 8784 определил первый способ примешать предварительно распределённый ключ к сеансовому материалу IKEv2. Он предполагает использование при первоначальном установлении, но не защищает этим PPK саму начальную IKE SA от рассматриваемого квантового противника. RFC 9867 не отменяет тот механизм, а добавляет два новых пути.

Первый использует IKE_INTERMEDIATE — обмен до аутентификации, определённый RFC 9242. Инициатор предлагает идентификаторы PPK, ответчик выбирает один из них и может вернуть подтверждение. Примешивание происходит до IKE_AUTH, поэтому вносит вклад в защиту начальной IKE SA и аутентификации. Если другие промежуточные обмены тоже пересчитывают материал, операция с PPK должна быть последним пересчётом перед следующим обменом. Порядок — часть утверждения о безопасности.

Второй путь использует CREATE_CHILD_SA. Свежий PPK может участвовать в создании или смене ключей Child SA либо в смене ключей IKE SA без разрушения всей существующей связи. Ротация становится практичной, но под одной логической сессией появляются разные родословные. Старая IKE SA, продолжающиеся Child SA, новая Child SA и обновлённая IKE SA не вправе автоматически наследовать одну отметку «защищено PPK».

Множественные обмены ключами из RFC 9370 и терминология гибридных постквантовых схем из RFC 9838 дают контекст. Перечень алгоритмов показывает возможности, журнал обмена — событие. Ни то ни другое отдельно не доказывает, что конкретный вклад попал в ключи конкретной SA.

Совпадение значения ещё не означает разрешение

RFC 9867 использует два зарегистрированных уведомления: USE_PPK_INT со значением 16445 и PPK_IDENTITY_KEY со значением 16446. Реестр IANA подтверждает назначения. Эти видимые элементы помогают наблюдению, но не являются секретным PPK и не дают права записывать его в журнал.

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

На этапе IKE_INTERMEDIATE ответчику иногда приходится выбирать PPK до того, как он знает аутентифицированную личность инициатора. Затем локальная политика может выяснить, что этому узлу выбранный ключ не положен. RFC 9867 говорит, что в таком случае обмен следует прервать, но разрешает продолжение, если его допускает локальная политика. Найти материал, подтвердить значение, установить личность и разрешить их сочетание — четыре решения.

Автоматизация легко сжимает их в один флаг. Хранилище сообщает «найдено», подтверждение — «значение совпало», аутентификация — «это такой-то узел». Только политика сообщает «разрешено». Общая зелёная отметка стирает последовательность и владельца каждого решения.

Создана, отклонена и удалена

Самый наглядный случай возникает в CREATE_CHILD_SA. Инициатор просит свежий PPK. Если ответчик не поддерживает расширение, не настроен, не находит идентификатор или имеет другое значение, в ответе нет PPK_IDENTITY_KEY. Тем не менее обычный IKEv2 всё ещё способен создать новую SA.

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

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

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

Документ о переходе, но никогда не о секрете

Предлагаемый документ о примешивании PPK — редакционный контрольный объект. Это не поле RFC 9867, не новое расширение и не предписание собирать данные; сам PPK в него никогда не входит.

Для каждой созданной или обновлённой SA он фиксирует тип обмена и родословную родительской IKE SA. Он различает путь RFC 8784 и пути RFC 9867. Можно сохранить несекретный идентификатор либо приватную отпечатку, состояние предложения и выбора, результат подтверждения и момент, когда стала известна аутентифицированная личность. Наблюдаемая обязательная или необязательная политика, её версия, принимающая сторона и владелец исключения связываются отдельно.

Далее записывается порядок выработки. Если промежуточных пересчётов несколько, была ли операция PPK последней, как требуется? SPI и идентификаторы привязывают документ к SA, но сами не доказывают вычисление. Создана, установлена, принята, первый пакет, последний пакет и удалена остаются разными состояниями, дополненными причиной отката, решением об отмене и датой пересмотра.

Граница наблюдения должна быть явной. Сетевой захват показывает уведомления и трафик, но не всегда внутреннее состояние ключевого расписания. Реализация может засвидетельствовать применение вклада, не раскрывая секрет. Межвендорное утверждение требует ограниченного доверия. Поэтому документ называет компонент-источник каждого наблюдения и помечает выводы как выводы.

Отчёт о миграции закрывается на границе SA

Постквантовая мотивация не оправдывает лозунги. RFC 9867 объясняет, что симметричные примитивы сейчас не считаются подверженными тому же воздействию криптографически значимого квантового компьютера, что обсуждаемые алгоритмы с открытым ключом. Сильный PPK до аутентификации добавляет путь защиты. Это не утверждение о существовании машины, не прогноз даты и не сертификат безопасности продукта.

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

Надёжный отчёт считает точные SA и исходы: RFC 8784, IKE_INTERMEDIATE, смену ключей со свежим PPK, необязательный откат, ошибку подтверждения или создание с последующим обязательным удалением. Это разнообразие не мусор для усреднения, а карта реальных решений.

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

Источники