Кратко

  • HASH(1) аутентифицировал предложение инициатора и Ni, HASH(2) — выбор responder и Nr, а HASH(3) доказывал responder, что инициатор получил второй nonce. Все три опирались на уже аутентифицированную Phase 1 SA.
  • Базовый Quick Mode не содержал четвёртого подтверждения для инициатора. Ни один HASH не включал возврат от ядра, установленные selectors, счётчик защищённых пакетов или результат приложения.

Фраза «IKE завершён» описывает состояние процесса. Фраза «IPsec работает в обе стороны» описывает состояние двух систем и потока между ними. RFC 2409 давал материалы для первой фразы, но не превращал её автоматически во вторую.

IKE объединил framework ISAKMP из RFC 2408, IPsec DOI из RFC 2407 и механизмы Oakley и SKEME. ISAKMP задавал форматы и управление SA, не навязывая одну аутентификацию и один key exchange. IKE определил конкретные последовательности и derivation.

Phase 1 строила двунаправленную аутентифицированную ISAKMP SA. Main Mode требовалось реализовать, Aggressive Mode рекомендовалось. Оба использовали ephemeral Diffie-Hellman, но по-разному упорядочивали сообщения и защищали личности.

Quick Mode принадлежал только Phase 2. Он использовал готовый Phase 1 context для переговоров о не-ISAKMP SA, в том числе AH и ESP. Одна дорогая родительская аутентификация могла обслужить много дочерних обменов.

Пара Initiator Cookie и Responder Cookie определяла родительскую SA. Message ID определял один Quick Mode. Первый IV вычислялся из последнего CBC-блока Phase 1 и Message ID.

Поэтому несколько Quick Mode могли идти одновременно с независимыми IV-цепочками. Повтор или задержка в одном обмене не должны были сдвинуть криптографическое состояние другого.

Message ID был ключом состояния, а не credential. Включение в HASH связывало выбранное состояние с аутентифицированным transcript. Оно не давало разрешения и не показывало установку.

Первое сообщение несло HASH(1), предложение SA и Ni, а при необходимости KE и IDci/IDcr. Payload после ISAKMP header шли зашифрованными под Phase 1 SA.

HASH(1) охватывал Message ID и полное сообщение после самого HASH, включая payload headers и без encryption padding. Responder мог убедиться, что владелец Phase 1 state отправил именно это предложение и nonce.

Аутентифицированное предложение не было принятым решением. Локальная policy responder выбирала transform или отклоняла набор. На этом этапе runtime SA могла вообще не существовать.

Второе сообщение возвращало HASH(2), выбранную SA и Nr. В расчёт перед остальным ответом добавлялся Ni. RFC называл это liveness proof.

После проверки инициатор знал, что владелец Phase 1 context получил Ni, сделал выбор и создал новый Nr. У обеих сторон появлялись входы для одинакового candidate KEYMAT.

Третье сообщение содержало HDR*, HASH(3). PRF получала нулевой октет, Message ID, Ni и Nr. Responder мог доказать, что инициатор видел его nonce и контролировал аутентифицированное состояние.

Последнюю квитанцию получал responder. Инициатор её отправлял. Четвёртого базового сообщения, подтверждающего получение и проверку HASH(3), не было.

Это узкий вывод из определённой последовательности, а не приписывание RFC обещания, которого в нём нет. Retransmission, защищённый трафик и отдельные механизмы могли добавить наблюдения. Они не меняли содержимое базового transcript.

Commit и CONNECTED из RFC 2408 решали соседнюю задачу синхронизации и сами допускали потерю финального сообщения. Настоящий материал этого текста — три HASH и отсутствие двусторонней installation receipt.

Даже четвёртое сетевое сообщение не доказывало бы две установки. IKE daemon договаривался. Kernel или accelerator устанавливал SPI, ключи, algorithms, lifetimes, selectors и replay state.

Получение UDP datagram не равно успешной расшифровке. Расшифровка не равна HASH verification. Проверка не равна state advance. State advance не равен системному вызову. Системный вызов не равен пакету. Пакет не равен полезному сервису.

Ni и Nr давали свежесть и мешали replay старого обмена создать ложные SA. Без KE в Quick Mode KEYMAT выводился из SKEYID_d, protocol, SPI и двух nonce.

Ключи обновлялись, но не получали PFS, независимую от Phase 1 exponentiation. С optional KE выполнялся новый Diffie-Hellman, а его shared secret добавлялся в KEYMAT. Тогда Phase 2 keys получали PFS.

KE было необязательно использовать, но обязательно поддерживать. При использовании DH group должен был быть согласован во всех transforms соответствующих proposals. Client identities тоже должны были одинаково относиться ко всем SA набора.

PFS ограничивает раскрытие прошлых ключей при будущем компромиссе. Она не подтверждает SAD write, SPD selector, hardware programming или первый пакет. Сильное криптографическое свойство не является общей зелёной лампой.

IDci и IDcr отделяли authenticated peer от traffic subject. В Phase 1 могла аутентифицироваться gateway, а в Phase 2 она представляла hosts, networks или protocols.

Успешная аутентификация gateway не давала ей права на любую пару selectors. HASH включал identity fields в защищённый transcript. Локальная policy решала, разрешено ли peer создать такую связь.

Responder выбирал transform и SPI, закрепляя выбор в HASH(2). Инициатор подтверждал получение через HASH(3). Затем установка могла сломаться из-за памяти, конфликта selectors, lifetime conversion, driver, accelerator или поздней policy check.

Эти результаты не могли задним числом войти в уже вычисленный HASH. Если dashboard называл Quick Mode completion доказательством data plane, он расширял смысл протокольного события.

Правила IV показывали правильную дисциплину. Первый IV зависел от Phase 1 и Message ID, дальнейшие — от предыдущего ciphertext конкретного обмена.

RFC советовал не обновлять running IV по факту получения. Decrypted message должна пройти sanity check и действительно продвинуть IKE state machine. Валидная retransmission не была новым переходом.

Один daemon уже различал приём, decrypt, validation и advance. Key derivation, kernel install и packet processing добавляли новые границы. Другая сторона имела такую же отдельную цепь.

UDP позволял HASH(3) потеряться. Инициатор мог повторить его, не увидев защищённого трафика. Responder должен был узнать retransmission и не повторять локальные эффекты.

Поэтому нужны две квитанции. На стороне инициатора: HASH(2) verified, HASH(3) sent, KEYMAT derived, inbound/outbound SA installed, counters. На стороне responder: HASH(3) received and verified, complementary SAs installed, selectors active, counters.

Модель слоёв реальности Lu Heng не позволяет одному событию брать доказательную силу другого. Message ID — correlation, HASH — authenticated transcript, nonce и Diffie-Hellman — derivation, policy — authority, SAD/SPD — executable state, counters — packets, application check — outcome.

Agency problem проявляется в переходах. Credential authority связывает Phase 1 identity. Policy owner разрешает Phase 2 selectors. IKE daemon ведёт обмен. Kernel и accelerator устанавливают. Operations видит packets. Service owner оценивает пользу.

Minimum common specification не должна была унифицировать каждую policy database и kernel API. Она унифицировала сообщения и calculations. Local autonomy сохранялась вместе с ответственностью за local receipts.

Running-code primacy требует хранить всю связь: cookies, Phase 1 credential fingerprint и auth result, Message ID, IV origin, Ni, Nr, KE, proposals, SPIs, HASH checks, policy revision, install request и return, runtime SAs, selectors, counters и application probe.

С такой цепью отказ получает адрес. Если responder не видел HASH(3), его transcript не закрыт. Если оба daemons завершили обмен, а одной SA нет, отказ в installation. Если counters растут с обеих сторон, а сервис не работает, проблема после IPsec.

RFC 2409 опубликован в ноябре 1998 года. RFC 4109 обновил algorithm requirements IKEv1. RFC 4306 заменил семейство 2407/2408/2409 на IKEv2; RFC 7296 позднее стал IKEv2 Internet Standard. В 2023 году IKEv1 получил статус Historic, а RFC 9395 объявил его устаревшим и закрыл связанные registries.

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

Источники