Кратко

  • AES-XCBC-MAC-96 передаёт первые 96 бит результата длиной 128 бит как проверочное значение IPsec. RFC 3664 использует все 128 бит как выход PRF для IKE.
  • RFC 4434 сохраняет этот выход и результат для 128-битного ключа, но снимает требование единственной длины ключа. В IKEv2 при генерации ключевого материала действует фиксированная длина, а при аутентификации общим секретом — переменная.

Три разных длины

В этой истории «128 бит» обозначает не одну величину. RFC 3566 вычисляет 128-битное значение AES-XCBC, но передаёт только его первые 96 бит в поле проверки ESP или AH. Получатель вычисляет полное значение и сравнивает те же 96 бит. Это укороченное поле служит для проверки пакета; оно не представляет весь возможный результат конструкции. RFC 3566

У IKE была другая задача. Выход псевдослучайной функции (PRF) участвует в создании ключей, поэтому RFC 3664 считал 96-битный выход слишком коротким для длительного применения в IKEv1 или IKEv2. Изменение было узким: использовать AES-XCBC без последнего шага усечения. Так выход PRF стал 128-битным. Это не означает, что каждый ключ, полученный через IKE, имеет длину 128 бит: выход поступает в предусмотренное протоколом выведение ключей. RFC 3664

RFC 3664 унаследовал и другое ограничение AES-XCBC-MAC-96: ключ должен быть ровно 128-битным. Выход оставался полным, но входной ключ имел фиксированную длину. Для общих секретов IKE другой длины это было неудобной границей. Позднейший документ не меняет результат для 128-битного ключа, а уточняет нормализацию входа перед операцией AES. Страница RFC 3664 и исправления Исправления RFC 3664

Исправление 2006 года касалось входа

RFC 4434 убрала требование, что ключ должен быть ровно 128-битным. Ключ такой длины используется без изменений. Более короткий ключ дополняется нулевыми битами справа до 128 бит. Если длина достигает 129 бит, PRF запускается повторно: с 128-битным ключом из нулей и слишком длинным ключом в качестве сообщения. Полученный выход становится нормализованным ключом. Это не обычное усечение и не универсальная хеш-функция. RFC 4434

Фраза «тот же алгоритм» может скрыть два вопроса: какие результаты передаются по протоколу и какие входы принимают реализации. RFC 4434 говорит, что для 128-битных ключей результат на проводе совпадает с RFC 3664. Ключи другой длины больше не отклоняются, а преобразуются в 128-битный ключ AES. Выход PRF остаётся полным 128-битным значением XCBC, а не 96-битным проверочным полем ESP/AH. Страница RFC 4434 и исправления Исправления RFC 4434

В IKEv2 у PRF две роли

Преемник также различает два применения внутри IKEv2. При создании ключевого материала AES-XCBC-PRF-128 считается PRF фиксированной длины; процедура IKEv2 разделяет вклад двух nonce. При аутентификации общим секретом RFC 4434 считает её переменной по длине, поэтому сам секрет не обязан иметь 128 бит. Документ называет логику несколько запутанной и объясняет её стремлением обеспечить взаимодействие реализаций, следующих фиксированному правилу RFC 3664, и реализаций с более гибкой трактовкой. RFC 4306 RFC 4434

Это уточнение интерфейсного контракта, а не свидетельство конкретного сбоя реализации или широкого внедрения. RFC 4434 сохранила полный выход и результат для 128-битного ключа, а также описала преобразование коротких и длинных входов. Более поздние рекомендации RFC 8221 касаются алгоритмов проверки ESP/AH; они не доказывают согласование PRF в IKE или поведение конкретных реализаций. RFC 8221

Историю проще читать как отдельные шаги: усечь MAC для поля пакета, оставить полный результат для PRF IKE, нормализовать входной ключ в соответствии с его назначением.

Источники