Кратко

  • RFC 3961 отделил базовый ключ от ключа конкретной операции и сделал ненулевой 32-битный номер применения входом шифрования и проверки.
  • Упрощённый профиль выводил отдельные Kc, Ke и Ki; успешный результат подтверждал выбранный контекст, но не полномочие пользователя и не итог услуги.

В RFC 3961 номер применения считался известным атакующему. Его задача состояла не в секретности, а в разделении: одинаковый базовый ключ должен давать разный криптографический материал для разных сообщений и ролей.

Документ 2005 года создал интерфейс между Kerberos и шифрами. Полный профиль задавал формат ключа, преобразование строки и случайных битов, вывод ключей, состояние, шифрование, целостность и PRF. Номер etype лишь указывал на такой профиль. Он не доказывал поддержку реализацией, включение администратором, выбор в обмене или безопасность результата.

Материал ранее находился в RFC 1510. RFC 4120 позднее заменил эту спецификацию Kerberos V5 и использовал отдельную криптографическую абстракцию. Приложение называло базовый ключ и применение, не управляя внутренним IV или представлением производного ключа.

Одна основа, три функции

Номер применения — открытое беззнаковое 32-битное число; ноль запрещён. В упрощённом профиле к его четырём байтам добавлялись 0x99, 0xAA или 0x55. Так получались Kc для checksum, Ke для шифрования и Ki для контроля целостности. Базовый ключ предназначался только для вывода.

Причина была практической. RFC отмечал программы, разделявшие ключи между Kerberos v4 и v5: операция старой версии могла стать оракулом для атаки новой. Случайный confounder снижал предсказуемость, а разделение применений ограничивало перенос криптографической возможности. Это модель угрозы, а не заявление о конкретном инциденте.

Успех проверки не завершал решение

Расшифрование должно было проверить целостность и отбросить данные при ошибке. Успех связывал шифротекст, производный ключ, применение и тег. Он сам по себе не устанавливал законного владельца базового ключа, правильность выбранного применения, свежесть билета, отсутствие повтора, прикладное разрешение или оказание услуги.

RFC 6113 применил рамку к общей предаутентификации, не превратив её в прикладную авторизацию. Аудит должен соединять тип сообщения, предложенный и выбранный etype, несекретную версию ключа, применение и норму, хеш объекта, версию библиотеки, целостность, свежесть, replay-проверку, билет, решение приложения и наблюдаемый итог.

Рамка пережила старые алгоритмы

RFC 3962 описал AES-типы. RFC 4537 разделил список поддержки и фактический выбор. Реестр IANA показывает назначения и ссылки, а не развёртывание.

RFC 6649 отменил рекомендацию single DES, а RFC 8429 обновил RFC 3961 и вывел другие старые алгоритмы. RFC 8009 сохранил общую рамку, но отказался от упрощённого профиля ради проверки шифротекста до расшифрования. Интерфейс оказался долговечнее первой конструкции.

Страница RFC Editor и Datatracker фиксируют публикацию. Errata различают подтверждённую поправку Unicode, отложенный вопрос DES и отклонённое предложение. Эти статусы не доказывают производственный сбой.

RFC 3961 сделал фразу «ключ сработал» недостаточной. Криптографическое свидетельство требовало применения, профиля и сообщения. Право выполнить следующий шаг оставалось у приложения.

Источники