Кратко

  • RFC 2403 и RFC 2404 записывают в ESP или AH первые 96 бит вычисленного HMAC, хотя полные выходы и требования к ключам у них различаются.
  • Позднейшие требования к реализации ESP/AH разделили эти алгоритмы: RFC 8221 указывает для HMAC-MD5-96 MUST NOT, а для HMAC-SHA1-96 — MUST-. Общая длина тега никогда не означала одинаковую оценку безопасности.

Одно поле — две конструкции

В ноябре 1998 года RFC 2403 и RFC 2404 определили преобразования аутентификации с секретным ключом для Encapsulating Security Payload (ESP) и Authentication Header (AH) в IPsec. Один документ сочетал HMAC с MD5, другой — с SHA-1. Оба механизма предназначались для аутентификации источника данных и защиты целостности, если общий секрет известен только сторонам связи. Ни один из них сам по себе не обеспечивал конфиденциальность.

Видимое в пакете число было одинаковым: 96 бит. Полный результат HMAC-MD5 в RFC 2403 равен 128 битам, а HMAC-SHA-1 в RFC 2404 — 160 битам. Для обоих преобразований отправитель помещает в поле аутентификатора первые 96 бит. Получатель вычисляет HMAC целиком и сравнивает те же первые 96 бит. Такая длина совпадала со значением по умолчанию для AH и давала разным конструкциям одинаковый размер на линии. Она не превращала полные дайджесты в 96-битные хеши.

Требования к ключам тоже различались: RFC 2403 требует 128-битный ключ HMAC, RFC 2404 — 160-битный. Значит, одинаковая длина поля сосуществовала с разной длиной полного результата и фиксированного ключа. Важны были идентификатор согласованного преобразования и управление ключом; одни лишь видимые биты тега не описывали весь механизм.

Стойкость к коллизиям — не весь вопрос о HMAC

Документы 1998 года не приравнивали коллизию неключевого хеша к немедленному взлому HMAC. RFC 2403 отмечал, что HMAC в меньшей степени зависит от сильной стойкости MD5 к коллизиям, чем подписи на MD5, и что на тот момент практических атак на HMAC-MD5-96 не было известно. RFC 2404 приводил аналогичную, привязанную ко времени оценку для HMAC-SHA-1-96. Это исторические заключения, а не гарантии на будущее.

История требований к реализации показывает, как менялась оценка, хотя длина тега не стала решающим критерием. В 2005 году RFC 4305 указывал HMAC-SHA1-96 как MUST, а HMAC-MD5-96 как MAY. RFC 4835 в 2007 году сохранил это различие и отметил, что известные тогда слабости коллизионной стойкости не должны влиять на использование этих хешей с HMAC. RFC 7321 в 2014 году упомянул теоретические результаты против HMAC-MD5, но не нашёл очевидной практической уязвимости и не счёл срочное удаление из существующих протоколов необходимым; несмотря на слабость SHA-1 к коллизиям, документ продолжал считать HMAC-SHA-1 безопасным.

Опубликованный в 2017 году RFC 8221 провёл более чёткую границу в требованиях к реализации ESP/AH: для HMAC-MD5-96 появился MUST NOT, а HMAC-SHA1-96 был понижен с MUST до MUST-. Запрет первого объяснялся известной уязвимостью MD5 к коллизиям; понижение второго связывалось с общеотраслевой тенденцией отказываться от SHA-1. Это не означало, что изменилось 96-битное поле или что RFC 2404 стал определять другой тег.

Таблица статусов — не запись сетевого трафика

Позднее RFC 9395 обновил RFC 8221 и изменил реестр преобразований IKEv2, где запись AUTH_HMAC_MD5_96 получила статус DEPRECATED. Этот реестр не является таблицей требований к реализации ESP/AH из RFC 8221. Похожие имена встречаются в соседних контекстах IPsec, поэтому статус следует читать вместе с указанием протокола и областью документа.

Эти документы фиксируют параметры протоколов и датированные рекомендации по реализации. Они не подсчитывают установленное оборудование, не называют последнюю согласованную ассоциацию безопасности HMAC-MD5 и не устанавливают общую дату вывода из эксплуатации. Оператору нужно различать выбранный протокол, идентификатор преобразования, возможности обеих сторон, установленную ассоциацию и наблюдаемый трафик. 96-битный тег — только часть свидетельств.

Источники