Кратко

  • В обменах с ответом RFC 2025 формирует Context ID из randSrc инициатора и следующего за ним randTarg цели. Наличие обеих частей означает, что каждая сторона участвовала в отделении нового контекста от прежних.
  • Односторонний SPKM-2 состоит только из SPKM-REQ. Цель не вносит случайного значения и должна поверить в свежесть значения инициатора либо отклонить контекст. key-src-bind усиливает привязку запроса и ключа, но не создает вклад цели.
  • Защита от воспроизведения при установлении контекста и необязательные сервисы replay/sequence для последующих сообщений — разные уровни. Context ID также не доказывает авторизацию, доставку или деловой результат.

Квитанция, у которой видны два автора

RFC 2025 определяет Simple Public-Key GSS-API Mechanism — SPKM. В токенах установления контекста много полей, но способ построения Context ID особенно удобен для доказательного анализа. Инициатор передает randSrc. Если обмен предусматривает ответ, цель добавляет randTarg. Их последовательное объединение затем обозначает контекст в следующих токенах.

Происхождение частей можно установить. Инициатор видит, что цель создала материал именно для этого обмена; цель знает, что ее новое значение включено рядом со значением инициатора. Поэтому randSrc || randTarg можно назвать двусторонней квитанцией, но лишь для узкого утверждения: с высокой вероятностью этот контекст отделен от старых контекстов.

RFC 2025 не требует непредсказуемости этих случайных значений. Требуется высокая вероятность того, что они никогда раньше не использовались. Их назначение — не повторяться между контекстами, а не хранить тайну. Более впечатляющее описание случайности не расширяет доказательство.

Единственный обмен без вклада цели

SPKM-1 всегда включает ответ цели. При односторонней аутентификации используются SPKM-REQ и SPKM-REP-TI; при взаимной добавляется SPKM-REP-IT. Взаимный SPKM-2 тоже содержит ответ. Во всех этих случаях у цели есть токен, в который можно поместить randTarg.

Односторонний SPKM-2 — исключение. Обмен заканчивается после одного SPKM-REQ, поэтому обратного токена для случайного значения цели нет. Context ID состоит только из значения инициатора. Спецификация прямо описывает выбор цели: довериться тому, что инициатор предоставил свежее значение, либо отклонить контекст.

Это не просто сокращение числа сетевых проходов. В обменах с ответом принимающая сторона помещает собственное свидетельство неповторения в общий идентификатор. В одностороннем варианте цель лишь оценивает заявление инициатора. Context ID остается полезным идентификатором, но перестает быть свидетельством совместно созданной свежести.

Что доказывает key-src-bind

Для одностороннего SPKM-2 предусмотрена отдельная защита. Если алгоритм установления ключа сам не связывает имя источника с ключом контекста, SPKM-REQ должен содержать key-src-bind: MD5-дайджест кодированного имени источника и предлагаемого ключа.

Это значение помогает цели рассматривать заявленный источник, полученный токен и ключ как части одного запроса. RFC также связывает его с доверием цели к свежести токена и предлагаемого ключа. Но поле по-прежнему создается внутри запроса инициатора. Оно не добавляет ответ, не порождает randTarg и не показывает, что цель создала свежий материал.

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

Два уровня защиты от повторения

SPKM может проверять повторение и порядок защищенных сообщений после установления контекста. Эти сервисы используют порядковые номера, если приложение их запросило. Они не возникают автоматически из случайных компонентов Context ID.

Общая спецификация GSS-API, RFC 2743, определяет replay и sequence для сообщений как выбираемые свойства контекста. Вызывающая сторона запрашивает их, принимающая сообщает доступный результат. Реализация может отметить дубликат или нарушение порядка дополнительным статусом и при этом все же передать подозрительное сообщение приложению. За транспорт токенов тоже отвечает приложение.

Поэтому аудит обязан разделять два вопроса. Отличена ли эта попытка установления от старых попыток? Проверялись ли последующие сообщения на дублирование и порядок внутри уже принятого контекста? Context ID относится к первому вопросу. Согласованные флаги, состояние последовательности и результаты проверки отдельных сообщений — ко второму.

История стандарта не равна истории внедрения

RFC Editor указывает RFC 2025 как Proposed Standard октября 1996 года; на момент проверки опубликованные исправления для документа не числились. В реестре SMI IANA сохраняются объектные идентификаторы SPKM-1, SPKM-2, SPKM-3 и ветви токенов SPKM GSS. Это подтверждает историю спецификации и распределения идентификаторов, но не современное применение.

Позднее RFC 2847 определил SPKM-3 как эквивалент SPKM-1 за исключением перечисленных изменений. Связь помогает проследить семейство механизмов, однако не меняет границу RFC 2025: Context ID следует читать только вместе со схемой обмена, которая его создала.

Надежный вывод краток. randSrc || randTarg фиксирует двусторонний вклад в свежесть контекста. Context ID одностороннего SPKM-2 фиксирует лишь вклад инициатора, даже при наличии key-src-bind. Ни тот, ни другой сам по себе не доказывает авторизацию сертификатом, выбор алгоритма, доставку сообщения или завершение операции.

Источники