Кратко

  • draft-ietf-kitten-sasl-ht-02 описывает двухсообщенческое семейство SASL для быстрой повторной аутентификации короткоживущим общим токеном.
  • Revision 02 — активный Internet-Draft рабочей группы KITTEN, находящийся в WG Last Call, с предполагаемым статусом Proposed Standard и сроком до 24 декабря 2026 года. Это не RFC и не результат внедрения.
  • Совпадение HMAC инициатора доказывает владение со стороны клиента. Взаимная аутентификация появляется только после того, как клиент проверит отдельный HMAC ответчика.
  • Доставка ответа, резервирование использования, отзыв, текущая авторизация, восстановление поколения сессии и результат приложения не следуют из одного server-side success.

У каждой стороны свой момент знания

SASL-HT экономит сетевое время после более сильной предыдущей аутентификации. Клиент получает эфемерный токен, теряет соединение и позже доказывает владение им. Сервер избегает полного повторения исходного механизма.

Сообщение инициатора содержит authcid, необязательные пары ключ/значение и HMAC от строки роли Initiator, данных channel binding и этих значений. Сервер вычисляет ожидаемое значение. Совпадение означает успешную аутентификацию инициатора; несовпадение должно завершиться отказом.

После этого сервер отправляет success response с собственными значениями и HMAC от Responder. Проект прямо требует, чтобы инициатор проверил это сообщение для достижения mutual authentication. Значит, сервер не может единолично засвидетельствовать, что взаимность завершилась.

Если ответ потерян, сервер знает, что вычислил доказательство; клиент не знает, кто ответил и чем закончилась попытка. Следующий retry может встретить уже использованный токен. Это не обязательно сбой или атака: это неопределённый результат между двумя наблюдателями.

Квитанции должны сохранять получение запроса, сравнение HMAC, резервирование токена, создание и отправку ответа, последующее продвижение клиента и commit расходования. Запись authentication=success без направления и времени стирает важную границу.

Разделение ролей не заменяет доставку

Разные литералы Initiator и Responder привязывают аутентификаторы к направлениям. Это препятствует механическому переносу одного HMAC в роль другого. Но role separation действует внутри вычисления, а не гарантирует доставку или проверку.

Для клиента доказательство сервера существует только после получения, разбора и сравнения responder message. Сервер может считать свою работу законченной раньше. Наблюдаемая последующая application activity может служить косвенной корреляцией, но её нельзя подменять утверждением о точной клиентской проверке без соответствующей телеметрии.

Операционный язык должен отражать различие: «инициатор подтверждён сервером», «ответное доказательство отправлено», «клиент продолжил по взаимно подтверждённой сессии». Каждая формулировка имеет собственный источник.

Выданный токен несёт происхождение

Application-specific extension обязано позволять запрашивать SASL-HT token. Возвращённый секрет должен быть новым, созданным криптографически стойким генератором и содержать не менее 128 бит энтропии.

Проект рекомендует сообщать предполагаемое имя механизма при выдаче. Использование с другим механизмом должно провалиться. Такая фиксация защищает от downgrade только тогда, когда pin сохранён в записи и доступен всем verifier.

Энтропия не доказывает, что предыдущая аутентификация была нужной силы, что issuer имел полномочия, что token относится к правильному сервису или что текущие права не изменились. Запись выдачи включает predecessor method, issuer, subject, service, mechanism pin, epoch, expiration, use limit и session lineage.

Проект также предупреждает: token не солится и проходит одну hash iteration, поэтому не подходит для долгоживущих shared secrets вроде паролей. Удобный временный store не должен стать постоянным credential root.

Channel binding может быть явно отсутствующим

Имена HT включают hash и суффикс ENDP, UNIQ, EXPR либо NONE. Первые варианты выбирают определённые TLS inputs. При NONE binding data — пустая строка.

Правильный HMAC с NONE не доказывает привязку, которой не было во входе. Dashboard должен сохранять полный mechanism name, TLS peer identity, binding type и безопасный digest либо явное отсутствие. Политика, требующая exporter binding, должна классифицировать NONE как policy failure даже при cryptographic success.

Mechanism pin при выдаче и binding при использовании — связанные, но разные receipts. Узел, получивший secret без pin, может проверить математику и одновременно нарушить политику исходной выдачи.

Аутентифицированные поля не становятся полномочиями

Обе стороны могут добавить key/value pairs. Их байты включены в соответствующий HMAC, поэтому защищены от изменения и атрибутированы владельцу token. Это удобно для downgrade hash и согласованного контекста.

HMAC не определяет schema. Он не решает, известен ли key, допустим ли type, может ли identity требовать session generation, не устарело ли значение и какое действие следует выполнить. Подлинный запрос может оставаться неавторизованным.

Нужны allowlist, schema version, parser, conflict rule и current authorization. Лог связывает message digest, parsing result, policy decision и resulting state transition. Фраза «клиент действительно сказал это» не превращается в «сервер обязан это сделать».

Single-use требует общей транзакции

В примере сервис отзывает успешно использованный token. Normative text рекомендует rotation или revocation и ограниченный lifetime по времени либо use count. Эти рекомендации не доказывают, что конкретный успешный HMAC уже изменил состояние всех nodes.

Два front end могут одновременно прочитать unused record и принять правильное доказательство. Предварительная reservation снижает риск, но может сжечь token при потерянном ответе. Post-response consumption оставляет окно повторного успеха. Partition policy должна быть явной.

Требуемая согласованность зависит от эффекта. Если после аутентификации всегда выполняется свежая авторизация и создаётся обратимая новая сессия, retry может быть допустим. Если token немедленно возвращает высокопривилегированный control state, двойное принятие способно вызвать необратимые действия.

Квитанция хранит token-record ID, reservation, use count, commit, revocation timestamp и acknowledged replica scope, но не raw secret.

0-RTT допускает replay доказательства, не действия

Initiator message разрешено поместить в TLS 1.3 early data. Дополнительный application payload, кроме необходимого framing, запрещён; responder должен abort SASL при его наличии. Причина — возможность replay ранних данных.

Повторная оценка идемпотентного auth message не делает идемпотентными платёж, удаление, публикацию или смену ключа. До non-idempotent work сервер завершает replay handling, use reservation и current authorization.

Сокращение RTT меняет порядок сообщений, но не убирает контрольные плоскости. Клиент по-прежнему проверяет responder HMAC, приложение интерпретирует контекст, distributed state фиксирует расходование.

Authentication identity не является authorization identity

Проект говорит, что HT не умеет переносить authzid и не защищает его. Он предлагает channel binding, а не SASL security layer. Успешный authcid требует сопоставления с текущим account state, roles, service scope и requested operation.

Токен, выданный до отзыва роли, может оставаться криптографически валидным. Авторизация должна смотреть настоящее. То же относится к session: queue cursor, document version, lock и transaction не входят автоматически в HMAC.

Для восстановления приложение называет session ID, predecessor generation, target generation, conflict policy и state hash. Если нужного состояния нет, можно создать новую сессию, отказать или потребовать full authentication. Ни один выбор не опровергает possession proof.

Полная цепочка без лишних секретов

Защищённый набор receipts связывает issuance, predecessor authentication, subject, service, pin, expiry, use limit, TLS peer, binding, digests двух сообщений, auxiliary schema, replay reservation, consumption, revocation, current policy, session generation, admitted operation и observed result.

Raw token, exporter material и reusable authenticators не копируются ради удобства. Цель — показать место остановки доказательств, не создать вторую базу секретов.

Итоговая формула многослойна: сервер подтвердил инициатора; клиент подтвердил responder; token consumption достиг указанного scope; current policy разрешила transition; application выдало указанный result. Если известно только первое, взаимность и результат ещё не доказаны.

Источники