Кратко

  • В датированной 1 октября 2026 года редакции draft-ietf-tcpm-tcp-ao-algs-08 прямо сказано, что предложенная KMAC256-KDF соответствует варианту KMAC# из NIST SP 800-56C Rev. 2. Набор его аргументов отличается от исходного KMAC256 стандарта SP 800-185. Счётчик длиной 32 бита со значением один в сетевом порядке байтов теперь объяснён как указатель версии функции вывода ключа.
  • Формула, два предложенных 128-битных MAC и тестовые векторы уже присутствовали в редакции 07. Новость состоит в точном толковании существующей схемы, а не в утверждённом RFC, новом формате TCP-AO или подтверждённой смене рабочих ключей.

Сбой аутентификации между двумя BGP-соседями легко принять за проблему общей секретной строки. Но если устройства по-разному понимают вызов KMAC, одинаковый мастер-ключ тоже не даст одинаковых ключей трафика. Проверка TCP-AO происходит на уровне байтов. Интерфейс управления, где у обоих устройств выбран пункт «KMAC256», не заменяет сверку вычисления. Именно для такой сверки полезно новое уточнение проекта.

В разделе 3.1.2 группа TCPM связала KMAC256-KDF с одношаговой функцией из раздела 4.1 NIST SP 800-56C Rev. 2, вариантом 3. В редакции 08 добавлено, что речь идёт о KMAC#, аргументы которого не совпадают с первоначальным определением KMAC256 в SP 800-185. Значение счётчика осталось единицей, кодируемой как 32-битное число в сетевом порядке байтов; теперь текст называет его маркером версии KDF. Сравнение редакций не показывает замены математической формулы или тестовых векторов. Изменился ориентир, по которому надо читать уже приведённую формулу.

В неё входят нулевой salt длиной 132 байта, счётчик, мастер-ключ Z, контекст TCP-соединения FixedInfo, 256-битная длина результата и ASCII-строка настройки KDF. Один вызов выводит 256-битный ключ трафика. Предложенный KMAC256-128 использует его для 128-битного кода аутентификации; альтернативный HMAC-SHA256-128 получает ключ через HKDF-SHA256. Обе кандидатные схемы и ограничение по месту для опций TCP описывались ранее: 16-байтный MAC занимает в составе TCP-AO 20 из 40 доступных байтов опций. Эту цену нужно учитывать, но выдавать её за открытие редакции 08 нельзя.

Практический критерий совместимости — сопоставить сначала выведенные ключи двух независимых реализаций, затем конечные MAC с опубликованными векторами для случаев с охватом TCP-опций и без него. Это редакционное предложение о порядке испытаний, а не новая программа сертификации IETF. При расхождении стоит последовательно проверить вариант KMAC, порядок аргументов, кодирование счётчика, контекст и требуемую длину выхода. По одному лишь сообщению о падении соединения причину определить невозможно.

Граница выводов остаётся узкой. Проект требует мастер-ключ не короче 256 бит и напоминает, что надёжный примитив не исправит слабый ключ или возможность обхода в конструкции протокола. В рассмотренных источниках нет статистики внедрения и описания реального сбоя изделий разных поставщиков. TCP-AO защищает TCP-соединение, по которому идёт BGP, но не устанавливает право объявлять каждый маршрут. Успех вывода ключа также не подтверждает готовность процедуры двусторонней смены ключевых эпох.

Datatracker относит документ к активным проектам рабочей группы TCPM со стадией I-D Exists. В шапке указан замысел Standards Track, а поле ожидаемого статуса в карточке показывает (None); ни то ни другое не означает принятого RFC. Сейчас можно подтвердить лишь более точное определение варианта для предложенной KDF. Прежде чем давать ему полномочия защищать рабочее соединение, двум сторонам необходимо доказать совпадение результата вычисления.

Источники