Кратко
- В агрессивном трёхсообщенческом примере RFC 2412 подписи можно было проверить, а KEYID отметить как аутентифицированный, пока общий секрет Диффи — Хеллмана оставался
uncomputed. - Доказательство общения не доказывало вычисление; вычисление не доказывало двустороннюю установку SA, прохождение защищённого пакета или результат приложения.
Слово «аутентифицировано» звучит как окончание процесса. В RFC 2412 оно обозначало только одну границу внутри процесса.
Документ вышел в ноябре 1998 года со статусом Informational и описывал OAKLEY. Протокол позволял двум аутентифицированным сторонам определить секретный ключевой материал на основе Диффи — Хеллмана, выбрать вспомогательные алгоритмы, получить прямую секретность и работать рядом с ISAKMP. Сам RFC не был стандартом Интернета и не утверждал, что один обмен уже установил рабочие состояния AH или ESP.
В агрессивном примере инициатор отправлял cookie, группу, открытое значение g^x, предложения алгоритмов, идентичности, nonce и подпись. Ответчик добавлял свой cookie, g^y, выбранные параметры, оба nonce и собственную подпись. Третья подписанная посылка завершала transcript.
RFC называл эти подписи доказательством общения, которое можно сохранить и позднее показать третьей стороне. Но следующая фраза ограничивала смысл доказательства: ключевой материал, подразумеваемый групповыми экспонентами, не требовался для завершения обмена.
Реализация могла сохранить x и g^y, отметить материал как uncomputed и вычислить его позднее.
Порядок обработки показывал это не как абстракцию, а как допустимую последовательность. Инициатор проверял подпись ответчика, добавлял g^y в состояние и мог вычислить (g^y)^x = g^xy. Но вычисление разрешалось отложить до отправки финального ответа. KEYID при этом уже помечался аутентифицированным. Ответчик после проверки последней подписи тоже менял состояние ключа на аутентифицированное, а затем должен был вычислить g^xy и связать его с KEYID.
Граница аутентификации была пройдена. Граница вычисления могла ещё оставаться впереди.
Устройство KEYID делает различие наглядным. Два cookie служили слабой защитой от засорения и одновременно образовывали повторно используемое имя ключевого материала. sKEYID обозначал секрет, названный этим идентификатором; он не передавался и в данном примере выводился из g^xy, nonce и cookie. Имя могло существовать раньше содержимого. Аутентификация имени не создавала секретные биты.
Эксплуатационные панели легко стирают эту разницу. Журнал пишет «authenticated», индикатор становится зелёным, приложение читает «готово», оператор предполагает симметричные SA и защищённый поток. Каждая следующая уверенность приписывается предыдущей квитанции без собственного доказательства.
Отложенное вычисление имело рациональную сторону. Модульное возведение в степень было дорогим. Его перенос за критический путь последнего сообщения мог уменьшить видимую задержку или распределить нагрузку процессора. Собеседник всё равно получал тот же подписанный набор полей. Совместимость не обязательно требовала одинакового внутреннего момента выполнения.
Но отложенная работа превращалась в обязанность хранения. Нужно было удержать правильный закрытый показатель, открытое значение партнёра, группу, cookie, nonce, идентичности и алгоритмы, а затем проверить, вычислить, вывести и связать всё без смешения сеансов. Сбой, истечение срока, перезапуск или повторное использование ссылки могли оставить правильный подписанный transcript и уничтожить возможность получить рабочий ключ.
Поэтому нужны отдельные квитанции. Квитанция transcript подтверждает подпись над конкретными полями. Квитанция проверки подтверждает допустимость открытого элемента группы. Квитанция вычисления подтверждает появление g^xy и производного материала. Квитанция привязки соединяет его с нужными идентичностями, алгоритмами и KEYID. Квитанция установки доказывает локальную SA. Встречная квитанция нужна для второго конца. Пакет и результат приложения подтверждаются позже.
Истинность одного слоя не даёт ему права свидетельствовать за следующий.
RFC 2412 уже советовал отвергать некоторые вырожденные значения и требовал хорошей случайности для cookie, nonce и показателей. Опубликованная поправка исправляет терминологию безопасных простых и простых Софи Жермен, не меняя механизм отложенного вычисления.
Позднее RFC 6989 усилил проверки открытых значений Диффи — Хеллмана в IKEv2, включая группы с малыми подгруппами. Недопустимая нагрузка KE должна была отбрасываться и не использоваться для создания IKE SA. Это правило 2013 года ничего не доказывает о прежних реализациях OAKLEY или IKEv1. Оно лишь подчёркивает последовательность: получить — не значит проверить, проверить — не значит вычислить, вычислить — не значит установить.
RFC 2409 объединил элементы ISAKMP и OAKLEY в IKEv1. Его Aggressive Mode также позволял отправить последнюю нагрузку без защиты ISAKMP SA и отложить возведение в степень до завершения переговоров. Но вывод ключей всё равно зависел от реального общего значения. Метка завершения не могла заменить вычисление.
IKEv2 перестроил процесс в поколениях RFC 4306, 5996 и 7296. В RFC 7296 значение SKEYSEED вычисляется из nonce и эфемерного общего секрета, после чего выводятся отдельные ключи. Тот же документ различает аутентифицированную IKE SA и дочернюю SA либо запрос конфигурации, которые ещё могут завершиться неудачей.
Это не та же машина состояний, что у OAKLEY. Это более поздний пример общей дисциплины: завершение управляющего слоя не доказывает готовность зависимого пути данных.
Документальная история также не равна установленному парку. RFC 2412 имел статус Informational. IKEv1 прошёл путь стандартизации, IKEv2 его заменил, требования к алгоритмам изменились, а RFC 9395 объявил IKEv1 и старые алгоритмы устаревшими. Публикация меняет рекомендацию, но не удаляет код из работающего устройства.
Принцип первичности работающего кода Лу Хэна даёт строгий способ читать эту историю. Документ определяет смысл перехода. Только работающая реализация создаёт доказательство его выполнения. Слои реальности нужно сохранять по отдельности: сообщение, подпись, проверка, вычисление, привязка, установка, пакет и результат сервиса.
Минимальная начальная спецификация указывает и границу свободы. Независимым реализациям требовались общие подписываемые поля, правила вывода и значения параметров. Им не обязательно выполнять экспоненцирование в один и тот же такт процессора, если локальный выбор не меняет безопасность и совместимость.
Однако выбирающий отсрочку контролирует невидимый интервал. Он обязан сохранить входные данные, точно показать состояние и снять все более сильные утверждения при неудаче вычисления. Приложение, которое несёт последствия, не должно угадывать смысл зелёного индикатора.
Uncomputed — честное историческое слово. Оно не обесценивает подпись. Оно не позволяет подписи доказывать вычисление, которого ещё не было.
Обмен был аутентифицирован. Секрет предстояло вычислить. SA предстояло связать и установить. Пакету — пройти, а сервису — подтвердить результат.
Надёжная система сохраняет отдельный глагол для каждого факта.
Источники
- История RFC 2412 в IETF Datatracker
- Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Лу Хэн — Проблема принципала и агента в управлении Интернетом
- Лу Хэн — Слои реальности и символическая власть
- Лу Хэн — Первичность работающего кода
- Реестры IPsec IANA
- Поправки к RFC 2412
- Сведения о RFC 2412
- RFC 2026 — Процесс стандартизации Интернета
- RFC 2119 — Нормативные ключевые слова
- RFC 2401 — Архитектура безопасности IP
- RFC 2408 — ISAKMP
- RFC 2409 — IKE
- RFC 2412 — OAKLEY
- RFC 4306 — IKEv2
- RFC 5996 — IKEv2
- RFC 6071 — Обзор документов IPsec и IKE
- RFC 6989 — Дополнительные проверки Диффи — Хеллмана
- RFC 7296 — IKEv2
- RFC 8247 — Требования к алгоритмам IKEv2
- RFC 9395 — Вывод IKEv1 из употребления
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
