Кратко

  • RFC 5926 требовал от полностью совместимой реализации HMAC-SHA-1-96, AES-128-CMAC-96 и соответствующие им KDF.
  • Обе схемы давали 96-битные теги, сочетая общую основу с вариантом для миграции.

Гибкость без согласия не работает

TCP-AO не выполняет аутентификацию на основе абстрактного обещания использовать «стойкую криптографию». Отправитель выводит ключ трафика, связанный с соединением, и вычисляет MAC конкретным алгоритмом. Получатель должен повторить ту же выработку и тот же расчет. Если пара различается, принятый тег не становится другим допустимым толкованием доказательства — его просто невозможно проверить.

Поэтому RFC 5926 совместил выбор с обязательным минимумом. Совместимая реализация должна была поддерживать HMAC-SHA-1-96, AES-128-CMAC-96, KDF_HMAC_SHA1 и KDF_AES_128_CMAC. Это не означало одновременное использование двух наборов в одном соединении и не вводило внутриполосное согласование в TCP. Речь шла о наличии у независимо созданных систем общих вариантов, которые можно настроить одинаково.

Одного имени MAC также недостаточно для полного контракта. KDF получает настроенные Master_Key и Context соединения, а также требуемую длину выхода, после чего формирует Traffic_Key для TCP-сегментов. Каждый MAC из RFC 5926 указывает связанную с ним KDF; одна KDF может применяться с несколькими MAC, но способ выработки ключа трафика не должен оставаться неопределенным.

Два примитива и ограниченное место в опции

HMAC-SHA-1-96 использует 160-битный ключ трафика и начинает с результата HMAC-SHA1. AES-128-CMAC-96 использует 128-битный ключ трафика и AES-CMAC. В обоих случаях значение в опции TCP-AO усекается до 96 бит. Это был инженерный компромисс между надежностью аутентификации и ограниченным пространством TCP-опции, а не утверждение, что исходные примитивы имеют лишь 96-битный выход.

При публикации в 2010 году HMAC-SHA1 рекомендовали как значение по умолчанию для пользовательского интерфейса из-за его широкой тогдашней поддержки. AES-128-CMAC сделали обязательным как отдельную альтернативу и путь миграции. Это историческое объяснение, а не современная рекомендация.

KDF для AES-CMAC принимает главные ключи переменной длины: если вход не содержит ровно 16 октетов, она выводит 128-битный ключ. Такая гибкость не делает слабый или предсказуемый ключ безопасным.

Что обеспечила основа — и чего она не обеспечила

Четыре обязательных компонента дали совместимому программному обеспечению общую точку опоры. Они не исправляли несовместимые настройки автоматически. Сторонам по-прежнему требовались одинаковые параметры и общий секретный материал, а ручная модель управления ключами оставляла согласование вне обмена TCP.

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

Источники