Кратко
- RFC 3962 задавал число итераций PBKDF2 четырьмя октетами без знака в порядке big-endian: явно присутствующее
00 00 00 00означало 4 294 967 296 циклов, а отсутствие поля — 4096, если KDC уже мог его передать. - Поддельное большое число могло занять процессор клиента, а малое — снизить стоимость перебора для атакующего. Защита требовала подтверждённого происхождения и локальных границ, а не одного «правильного» числа.
Обычная схема данных охотно превращает пустое поле в ноль, а ноль — в значение по умолчанию. Для RFC 3962 такая нормализация меняла протокол. Четыре нулевых байта были не пробелом, а самой дорогой командой, которую позволял формат.
Параметр преобразования строки в ключ состоял из четырёх октетов и представлял беззнаковое целое big-endian. Число задавало итерации PBKDF2. Особое правило сопоставляло полному нулю 4 294 967 296, или (2^{32}), циклов. Поэтому наименьшим выражаемым числом становилась единица.
Отсутствие поля трактовалось иначе. Если KDC уже имел возможность передать параметр, но не сделал этого, применялось 00 00 10 00, то есть 4096. Документ подчёркивал: это не общая рекомендация для базы Kerberos и не обязательная догадка при оптимистической предварительной аутентификации. Это всего лишь смысл пропуска в определённом контексте.
Состояние начиналось до первого байта
Надёжная модель должна была хранить и признак присутствия, и содержимое. Если декодер, API или база сводили null, пустой массив, пропущенное свойство и числовой ноль к одному состоянию, нагрузка могла вырасти в 1 048 576 раз. Признак присутствия был частью криптографической команды, а не служебной деталью.
RFC 3962 вышел в феврале 2005 года и встроил AES в профиль RFC 3961. Он определил блоки 128 бит, ключи 128 или 256 бит, CBC с похищением шифротекста и HMAC-SHA1-96. Типам шифрования назначили номера 17 и 18, контрольным суммам — 15 и 16. Они находятся в реестре параметров Kerberos IANA, но регистрация не доказывает включение или выбор в конкретном обмене.
PBKDF2 обрабатывал пароль и соль, получая временный ключ; затем функция RFC 3961 с константой kerberos выводила протокольный ключ. RFC 2898 был тогда источником PBKDF2 в PKCS #5, позднее его обновил RFC 8018. Выход AES-256 не даёт человеческому паролю 256 бит непредсказуемости. Итерации увеличивают цену проверки гипотезы, но не создают энтропию.
Один множитель выставлял счёт обеим сторонам
Рабочий фактор одинаково замедлял перебор атакующего и вычисление законного пользователя. Поэтому число итераций было компромиссом ресурсов, а не шкалой, на которой больше всегда означает безопаснее.
Если злоумышленник мог подделать ответ KDC и указать огромное число, клиент надолго занимал процессор выводом неверного ключа. RFC разрешал ограничить максимум против такого отказа в обслуживании; если предел вводился, он должен был быть не ниже 50 000. Для миллиардов циклов имело смысл также разрешить прерывание операции.
При поддельном малом числе выгода менялась. Наблюдая ответ клиента, противник мог дешевле проверять кандидаты. Отсюда возникал и локальный минимум. Полная политика соединяла нижнюю границу, верхнюю границу и доверие к источнику. Слепо принимать сетевое значение было опасно, но механически повышать его тоже.
Запись iterations=4096 не отвечает на вопрос о происхождении. Число могло прийти из аутентифицированного ответа KDC, незащищённой ошибки, кэша, локальной настройки, правила отсутствующего поля или тестового режима. Следовало знать и то, проверены ли границы до начала вычисления. Без этой связи одинаковое число описывает политику, совместимость или внедрение данных атакующим.
Оптимизация обмена превращала свежесть в обязанность
При оптимистической предварительной аутентификации клиент выводит ключ и отправляет защищённую метку времени до получения актуальных параметров KDC. При верной догадке это экономит сетевой раунд. Но без дополнительной информации число итераций остаётся предположением.
Даже значение, сработавшее для того же принципала несколько часов назад, могло устареть. RFC предполагал, что сайты будут повышать стоимость по мере роста вычислительных возможностей. Вместо вечного универсального числа он рекомендовал локальную настройку внутри принятых границ.
Исторический смысл не в том, что 4096 когда-то было ответом или 50 000 стало им навсегда. Меняются оборудование и экономика атак. Не меняется необходимость назначить владельца параметра, время наблюдения и путь обновления. Оптимизация, пропускающая запрос к KDC, заменяет свежий факт политикой и должна делать замену видимой.
Выведенный ключ ещё не означал доступ
Завершение PBKDF2 даёт материал ключа. RFC 4120 определяет дальнейшие билеты Kerberos V5, аутентификаторы, свежесть и защиту от повторов. Вывод сам по себе не подтверждает пароль, принятие KDC, срок билета, разрешение приложения или оказанную услугу.
RFC 4537 позднее разделил предложенные типы шифрования и выбор сервера. RFC 6113 обобщил предварительную аутентификацию и передачу параметров. RFC 8009 добавил профили AES/HMAC-SHA2, а RFC 8429 объявил ряд старых алгоритмов нежелательными. Ни один этап не превратил число или вывод в прикладное полномочие.
У режима похищения шифротекста была отдельная граница. Отсутствие расширяющего дополнения означало, что длина шифротекста точно раскрывала длину открытого сообщения. Если длину требовалось скрыть, это делал верхний уровень. Дополнительные итерации PBKDF2 не устраняли такую утечку.
Полезная цепочка аудита сохраняет наличие поля, исходные четыре октета, разобранное число, источник и его аутентичность, локальные пределы, тип шифрования, происхождение соли, версию библиотеки, время, ресурсы и отмену. Результаты предварительной аутентификации, билета, проверки повторов, разрешения и услуги идут отдельными событиями. Пароль и секретный ключ журналировать нельзя.
Карточка RFC Editor, история Datatracker и поиск опечаток фиксируют документ; на момент захвата поиск не показывал записей. Это состояние реестра, а не гарантия безошибочности программ.
Главное наследие RFC 3962 — не призыв выполнить миллиарды циклов. Оно в строгом различии: ноль, отсутствие и значение по умолчанию сообщают разные факты. Потеряв его, система теряет возможность объяснить, кто и на каком основании потребовал затраты.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
