Кратко

  • RFC 3526 дал узлам IKE общие наборы MODP-параметров: от группы 5 на 1536 бит до групп 14–18 размером от 2048 до 8192 бит. Документ не обещает фиксированного соответствия силе AES и отдельно требует, чтобы секретный показатель не стал слабейшим звеном.
  • Надёжная квитанция связывает идентификатор параметров с локальной политикой, энтропией и свежестью показателя, проверкой открытого значения партнёра, аутентификацией, остальной криптографической сюитой, жизненным циклом ключей и наблюдаемым защищённым трафиком. Transform ID доказывает выбор, а не качество всех действий после него.

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

Эта асимметрия провоцирует подмену доказательства. Большое публичное число начинают выдавать за подтверждение всего обмена. RFC 3526 такого вывода не разрешает.

Документ опубликован в мае 2003 года на Standards Track и сейчас числится на уровне Proposed Standard. Он определяет общедоступный математический материал — средство координации, но не аттестацию работающей системы.

Стандарт закрепил варианты, а не результаты

Для IKE понадобились группы сильнее четырёх существовавших тогда вариантов. RFC 3526 описал уже применявшуюся группу 5 на 1536 бит и добавил группу 14 на 2048 бит, 15 на 3072, 16 на 4096, 17 на 6144 и 18 на 8192 бит. Во всех используется генератор 2 и опубликованная конструкция простого числа.

Такие идентификаторы решают настоящую задачу совместимости. Два продукта могут сослаться на одни параметры, не пересылая и не изобретая новый модуль. Запись «группа 16» можно сопоставить со стабильным публичным определением.

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

Узкая квитанция гласит только: «для этого обмена выбраны такие параметры». Более сильный вывод требует другого источника доказательств.

В документе нет простой таблицы эквивалентности

RFC 3526 приводит заметно расходящиеся оценки размера конечного поля, сопоставимого со 128-, 192- или 256-битным симметричным шифром. Одна оценка помещает аналог 128 бит примерно к 3200 битам и требует гораздо больших размеров для следующих уровней; другие дают существенно меньшие числа для 192 и 256 бит.

Авторы не превратили спор в удобный рекламный ряд. Они опубликовали несколько групп и прямо отказались назначать каждой длине AES одну обязательную группу. Верхней границей стали 8192 бита, потому что ещё большие группы считались непрактичными на тогдашнем оборудовании.

Для аудита эта сдержанность принципиальна. Нельзя механически перевести «группа 18» в «гарантировано 256 бит безопасности», совместив две цифры. Эквивалентность зависит от модели атаки, криптоаналитической оценки, горизонта времени, соседних алгоритмов и исполнения.

Каталог предоставляет выбор. Он не отменяет инженерное решение и не консервирует оценки 2003 года навсегда.

Секретный показатель способен обесценить большую группу

Главное предупреждение находится во введении: размер показателя должен соответствовать системе и не становиться её слабым звеном. RFC требует более чем вдвое больше случайности, чем заявленная стойкость; для группы, рассматриваемой как 128-битная, в примере нужно свыше 256 бит случайности.

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

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

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

Открытое значение партнёра проверяется отдельно

Впоследствии RFC 6989 определил проверки для получателя IKEv2. Для семейства MODP на простых числах Софи Жермен, куда входят группы RFC 3526, получатель убеждается, что открытое значение r строго лежит в пределах 1 < r < p-1.

Результат этой проверки не закодирован в номере группы. Партнёр может предложить группу 14 и всё же прислать значение, которое реализация обязана отвергнуть. Согласование определяет применимое правило, но не доказывает его исполнение.

RFC 6989 также разделяет группы с малыми подгруппами и случаи повторного использования закрытого значения. Это разные ветви. Для некоторых групп при повторном использовании нужна соответствующая проверка подгруппы; иначе следует создать свежее значение и выполнить предписанную проверку диапазона.

В журнале события полезны хеш полученного значения, точный профиль валидации, версия реализации и итог. Фраза «DH-группа принята» смешивает распознавание параметров, проверку входа и разрешение политики в одно непрозрачное состояние.

Обязательная реализация не означает обязательное включение

RFC 7296 отделяет совместимость продукта от политики эксплуатации. Реализация IKEv2 предоставляет администратору управление допустимыми наборами, сравнивает полученные Transform ID с локальной конфигурацией и отклоняет неразрешённые варианты. То, что продукт обязан реализовать, оператор не обязан включать.

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

RFC 8247 показывает, как политика меняется. На момент публикации группа 14 стала обязательной к реализации, а группа 5 получила статус SHOULD NOT из-за недостаточного запаса. Тот же документ предупреждал о заметной цене очень больших групп, особенно для VPN-шлюзов и ограниченных устройств.

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

Согласованная группа не аутентифицирует сторону

Неаутентифицированный Диффи — Хеллман создаёт общий секрет с тем, кто участвовал в обмене. IKE добавляет методы аутентификации и связывает согласованный материал с более широким протоколом. RFC 3526 эти механизмы не заменяет.

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

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

Метод аутентификации, путь учётных данных, политика проверки, заявленная и принятая идентичности, привязка канала должны оставаться отдельными от идентификатора группы. Они коррелируют, но не наследуют доказательную силу друг друга.

Верхнюю границу задаёт вся сюита

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

Большие группы создают и нагрузку. Модульное возведение в степень требует ресурсов и может усилить риск истощения, если дорогое вычисление выполняется до аутентификации партнёра. Это не довод в пользу слабых групп; это требование фиксировать полное решение контроля.

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

Более поздний RFC 7919 определяет именованные группы для TLS в ином переговорном контексте, в частности чтобы не поощрять повторное применение параметров между протоколами. Это полезная точка сравнения, а не перенос правил TLS на IKE задним числом.

Реестр координирует настоящее, но не свидетельствует о рантайме

Текущий реестр IANA для IKEv2 перечисляет группы 5 и 14–18, ссылаясь на RFC 3526 как определение и на RFC 6989 как источник проверок получателя. Реестр отвечает, что означает идентификатор и где искать правила.

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

RFC 9395 закрыл реестры IKEv1 и объявил сам IKEv1 устаревшим. В перечне устаревающих алгоритмов этого документа новые группы Диффи — Хеллмана не появились. Это точный исторический факт, а не утверждение о равной предпочтительности всех оставшихся групп или безопасности старых развёртываний.

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

Свяжите группу с результатом цепочкой доказательств

Начните с точной версии протокола, документа RFC, Transform ID, хеша простого числа и генератора. Сохраните полное упорядоченное предложение, выбранную сюиту, контекст защиты от понижения, идентификатор локальной политики и решение об авторизации.

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

Привяжите к обмену доказательства аутентификации: метод, цепочку удостоверения либо идентичность PSK, политику проверки и принятого субъекта. Затем фиксируйте безопасные для хранения входы вывода ключей, идентификаторы алгоритмов, создание SA, смену ключей, отсутствие повторного использования и уничтожение секретов.

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

Граница доказательств

В этой статье не названо ни одной реализации, компании, оператора, VPN, шлюза, партнёра, пользователя, системы, сессии, атаки или компрометации. Здесь нет измерительных утверждений о распространённости, качестве энтропии, проверке открытых значений, повторном использовании, задержке, производительности, уровне безопасности или деловом ущербе в действующей среде.

RFC 3526 рассматривается как документ Standards Track от мая 2003 года, ныне записанный на уровне Proposed Standard. Более поздние RFC сохраняют собственные даты и области: RFC 6989 описывает проверки получателя, RFC 7296 — управление IKEv2, RFC 8247 — требования к алгоритмам своего времени, RFC 9395 — устаревание IKEv1. Ни один не доказывает соблюдение правил названным рантаймом.

Заметки Heng Lu об авторитете и работающем коде используются как явно обозначенная редакционная оптика. Они помогают отделить публичную координацию от локально проверенного исполнения, но не устанавливают намерение IETF и не являются криптографическим фактом.

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

Источники