Кратко

  • 24 августа 2026 года IESG одобрила draft-ietf-ipsecme-ikev2-pqc-auth-12 как Proposed Standard. На момент фиксации источников 27 августа документ оставался активным Internet-Draft в очереди RFC Editor, а не опубликованным RFC с номером.
  • Документ описывает применение ML-DSA и SLH-DSA в чистом режиме через существующий метод Digital Signature в IKEv2. Он не доказывает выбор алгоритма шлюзом, прохождение крупных сообщений, проверку AUTH, установление IKE SA или авторизацию Child SA.

Два одинаковых статуса, две разные сессии

В отчёте о миграции два VPN-шлюза отмечены зелёным статусом «готов к постквантовой защите». На обоих учётная запись содержит ключ ML-DSA, а версия ПО распознаёт алгоритм. Для инвентаризации они одинаковы.

Пакетная запись показывает иное. В первой сессии локальная политика разрешает возврат к ECDSA, и именно ECDSA указан в AUTH. Во второй крупные постквантовые данные разбиваются на части, но оперативный путь не доставляет набор, который партнёр способен полностью собрать. Ни одна IKE SA не была аутентифицирована ML-DSA.

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

Что именно одобрила IESG

Объявление от 24 августа одобряет двенадцатую редакцию «Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC» как Proposed Standard. Документ подготовила рабочая группа IP Security Maintenance and Extensions. Он не заменяет IKEv2, а добавляет постквантовые схемы в уже существующий общий формат подписи.

Процедурный статус имеет значение. 27 августа Datatracker показывал состояние «RFC Ed Queue», а RFC Editor ожидал проверки ссылок и форматирования. Проект датирован 21 августа и должен был истечь 22 февраля 2027 года. До публикации редакционные изменения ещё возможны. Называть его опубликованным RFC пока нельзя.

Новых запросов к IANA проект не делает. Он использует имеющиеся значения: Digital Signature — метод аутентификации 14, IKEV2_FRAGMENTATION_SUPPORTED — уведомление 16430, SIGNATURE_HASH_ALGORITHMS — 16431, SUPPORTED_AUTH_METHODS — 16443, Identity — хеш-функция 5. Реестр согласует значения между реализациями, но не хранит сведения о конкретном туннеле.

Реальный алгоритм указан внутри AUTH

В IKE_SA_INIT согласуются криптографические параметры, передаются nonce и значения обмена ключами. IKE_AUTH переносит идентификаторы и доказательства владения секретом и обычно согласует первую Child SA. Улучшение обмена ключами не является доказательством подписи.

RFC 7427 задаёт общий метод Digital Signature. Authentication Data начинается с DER-кодированного AlgorithmIdentifier, после которого идёт подпись. Наблюдаемый в AUTH идентификатор указывает фактически использованную схему и набор параметров.

Для ML-DSA и SLH-DSA новый проект выбирает чистый режим. Данные, связанные с данной сессией, поступают в алгоритм без внешнего предварительного хеширования. Поэтому оба партнёра должны включить Identity со значением 5 в SIGNATURE_HASH_ALGORITHMS; схему, которой нужна Identity, нельзя применять, если другая сторона значение 5 не объявила.

Но Identity 5 — не название подписи. Это правило обработки входа. Наличие значения в обоих направлениях подтверждает предварительное условие. Выбор и принятие подтверждают AlgorithmIdentifier, сертификат и итог проверки.

Объявленный метод ещё не выбран

Проект называет Certificate Request и SUPPORTED_AUTH_METHODS из RFC 9593 способами помочь партнёрам подобрать совместимый тип ключа. Второй механизм может передать упорядоченный список методов или схем.

Отправка уведомления и использование его содержимого необязательны для обеих сторон. Список сокращает неудачные попытки при наличии нескольких удостоверений, но не обязывает будущий AUTH. Шлюз способен объявить ML-DSA, затем выбрать ECDSA по политике, предъявить недоверенную цепочку или не пройти проверку.

FIPS 204 стандартизирует ML-DSA, FIPS 205 — SLH-DSA. RFC 9881 и RFC 9909 описывают идентификаторы, кодирование PKIX и ограничения применения. Эти документы не создают закрытый ключ, не выпускают сертификат, не выбирают корень доверия, не гарантируют производительность HSM и не доказывают совместимость двух продуктов.

Рабочая опись должна связывать соединение с идентификатором ключа, отпечатком сертификата, цепочкой издателя, key usage, криптографическим поставщиком, сборкой ПО и правилом подключения.

Размер превращает путь в часть доказательства

Проект приводит практические размеры. Открытый ключ ML-DSA-44 занимает 1 312 байт, подпись — 2 420 байт. Даже минимальная подпись SLH-DSA составляет около 7 856 байт. Цепочка сертификатов добавляет объём.

Поэтому партнёры с новым механизмом обязаны поддерживать фрагментацию сообщений IKEv2. RFC 7383 позволяет объявить IKEV2_FRAGMENTATION_SUPPORTED в IKE_SA_INIT и фрагментировать последующие сообщения с Encrypted payload. Сам IKE_SA_INIT этот формат использовать не может.

Поддержка не равна доставке. Межсетевой экран, NAT, балансировщик или путь с потерями может помешать сборке. При надёжном транспорте или известной достаточной PMTU фрагментация может не понадобиться. В доказательство входят объявления обеих сторон, число и размер зашифрованных фрагментов, повторы, сборка и конечный ответ.

Обмен ключами и подпись — разные свойства

Выражение «постквантовый VPN» часто объединяет конфиденциальность и аутентификацию. Обмен ключами создаёт общий секрет. Подпись подтверждает партнёра через идентичность, удостоверение и историю сессии.

RFC 9370 вводит несколько обменов ключами и прямо указывает, что сосредоточен на конфиденциальности, а аутентификацию не рассматривает. RFC 8784 добавляет предварительно согласованный секрет, но сохраняет существующие проверки аутентификации. Поэтому IKE SA может иметь постквантовый вклад в ключевой материал, а AUTH подписываться ECDSA или RSA.

И наоборот, ML-DSA в AUTH не раскрывает группы обмена ключами. Эти две оси нужно показывать отдельно.

После AUTH остаётся авторизация

Успешная проверка подписи подтверждает подписанные данные конкретной сессии под принятым удостоверением. Она не разрешает автоматически каждый Traffic Selector, подсеть, учётную запись или приложение. IKE SA может быть установлена даже при неудаче первой Child SA.

Проверяемое утверждение соединяет точную редакцию, ПО и криптографического поставщика, ключ и цепочку, объявления в двух направлениях, реальный AlgorithmIdentifier, фрагменты и сборку, проверку и личность IKE SA, причину возврата, политику и селекторы Child SA и фактический защищённый трафик. Только после этого «постквантово аутентифицирован» становится результатом исполнения.

Источники