Кратко

  • Специальная контрольная сумма 0x8003 несёт дайджест переданных приложением привязок канала, флаги запрошенных и доступных услуг, а при делегировании — KRB_CRED с перенаправляемым TGT.
  • Нулевой Bnd не удостоверяет канал, односторонний KRB_AP_REQ не подтверждает принимающую сторону, а передача учётных данных, MIC, Wrap и порядок токенов не доказывают авторизацию и приём приложением.

В Kerberos слово «билет» звучит как разрешение. Но билет может лишь доставить материал для следующей проверки. RFC 1964 особенно хорошо показывает эту границу: рядом находятся идентификатор механизма, запрос, флаги, делегированное удостоверение и защита сообщений, однако ни один элемент не принимает решение за следующий сервис.

Документ июня 1996 года закрепил OID механизма 1.2.840.113554.1.2.2. Начальный KRB_AP_REQ помечается TOK_ID 01 00, ответ KRB_AP_REP — 02 00, ошибка KRB_ERROR — 03 00. MIC имеет 01 01, Wrap — 02 01. Маркер выбирает синтаксис разбора. Проверка подлинности, времени, адресата и контекста выполняется отдельно.

Нули — это отсутствие входа

В аутентификаторе KRB_AP_REQ контрольная сумма типа 0x8003 используется как контейнер GSS-API. Четыре байта задают длину Bnd, равную 16, затем следует MD5 по ненулевым частям структуры channel bindings. Длины и целые числа входят в расчёт с заданным порядком байтов.

Если вызывающая сторона передаёт GSS_C_NO_BINDINGS, Bnd состоит из шестнадцати нулей. Это не отпечаток канала по умолчанию и не идентификатор TLS, сокета или адреса. Поле честно сообщает: данные о привязке не были предоставлены. Приложения должны заранее выбрать тип привязки и передать сопоставимые значения на обоих концах.

Следующие четыре байта содержат флаги делегирования, взаимной аутентификации, защиты от повторов, контроля порядка, конфиденциальности и целостности. Первые четыре отражают одновременно запрос инициатора и доступность функции; последние два — доступность защиты сообщений. Доступность ещё не означает применение, а запрос — завершение.

Взаимность подтверждается обратным токеном

Без mutual_req RFC 1964 задаёт одностороннюю схему. Цель не посылает инициатору подтверждение в ответ на KRB_AP_REQ. Цель может установить личность инициатора, но у инициатора нет подтверждения цели.

При запросе взаимности в APOptions появляется mutual-required, а в checksum — соответствующий флаг. Цель возвращает KRB_AP_REP или KRB_ERROR. Валидный KRB_AP_REP завершает успешный взаимный обмен; KRB_ERROR представляет отказ. Сам факт обратного трафика не позволяет объединять эти исходы.

Успешный KRB_AP_REP подтверждает контекст, а не будущую команду. Приложение может отклонить её по полномочиям, формату или состоянию.

KRB_CRED переносит возможность

При активном делегировании checksum содержит опцию 1, длину и KRB_CRED. Переданный TGT имеет флаг FORWARDABLE. Получатель может использовать такие данные для запроса билетов к другим сервисам.

Но потребуются проверка и расшифрование KRB_CRED, безопасное хранение, контроль срока, запрос в KDC и собственная политика целевого сервиса. Передача удостоверения не доказывает использование; использование не доказывает разрешение. Для каждого шага нужен новый журнал.

MIC и Wrap не знают бизнес-правил

MIC защищает целостность данных, переданных отдельно. Wrap переносит данные с целостностью и возможным шифрованием. Защищённый номер последовательности включает направление отправителя. При этом обнаружение повторов и нарушения порядка необязательно и может быть отключено по просьбе вызывающей стороны.

Успешная MIC подтверждает криптографическую связь данных с контекстом. Успешный Unwrap подтверждает обработку защищённого контейнера. Затем приложение ещё должно распознать содержание, проверить права, изменить состояние и сформировать собственный ответ.

RFC 4121 впоследствии обновил механизм, а RFC 6649 объявил слабые алгоритмы той эпохи устаревшими. Поэтому DES и MD5 из RFC 1964 нельзя предлагать как современный выбор. Историческая ценность в другом: минимальная общая спецификация даёт локально проверяемые переходы, не присваивая им власть над последующими решениями. Running-Code Primacy используется здесь как редакционная дисциплина, а не как источник фактов о создании RFC.

Источники