Кратко

  • В RFC 9594 Authorization Server разрешает Клиенту обратиться к ресурсу членства; KDC всё равно проверяет Join и только после успеха создаёт участника и выдаёт состояние, заданное прикладным профилем.
  • Действительный токен, запись участника, установленная версия ключей и успешная групповая операция — четыре разных факта, у каждого свой свидетель.

Устройство получает подписанный токен с правильным scope, ролями и сроком. Для системы идентификации работа закончена успешно. Но KDC мог токен ещё не увидеть. Защищённая связь могла не установиться. Запрос Join мог быть отклонён. Даже успешный ответ мог не превратиться в локально активный ключ.

RFC 9594 строит процесс вокруг этих разрывов. Первая фаза следует ACE: Клиент, Authorization Server и KDC в роли Resource Server выполняют авторизацию. Вторая фаза — фактическая выдача группового ключевого материала между Клиентом и KDC. Право попросить о входе не является самим входом.

Сервер авторизации разрешает постучать

Authorization Server применяет политику: решает, к каким ресурсам членства Клиент может обратиться и какие роли запросить. Токен обычно передаётся на /authz-info, после чего Клиент и KDC используют защищённую связь по выбранному транспортному профилю ACE — например, DTLS или OSCORE.

Затем Клиент отправляет POST на /ace-group/GROUPNAME. KDC сверяет группу, scope и роли с сохранённой авторизацией, выполняет проверки базовой спецификации и прикладного профиля. Только успешный Join добавляет Клиента в список текущих участников и возвращает необходимый материал.

Поэтому токен не доказывает доставку в KDC, живую защищённую связь, отправку и приём Join, совпадение ролей, проверку credential или proof-of-possession, создание ресурса узла и локальную установку. Он достоверно говорит лишь о решении своего издателя.

Постоянное имя может указывать на меняющееся состояние

GROUPNAME обозначает ресурс членства и после создания не меняется. Имя узла и NODENAME также инвариантны и уникальны среди текущих участников. Это даёт стабильную поверхность управления.

Криптографическое состояние обновляется. Параметр num обозначает версию текущего группового ключевого материала. Идентификаторы, индивидуальный материал, credentials участников и политики читаются в контексте профиля и версии. Два Клиента могут обращаться к одной группе и временно иметь разные эпохи.

Техническая errata 8239 добавляет обязательный num в пример получения credentials, где опубликованный текст его пропустил. Errata 8864 исправляет описание пустых фильтров. На момент исследования обе записи имели статус Reported и не доказывают дефект продукта. Они подчёркивают другое: credentials без версии недостаточно для восстановления рабочего состояния.

Прикладной профиль завершает договор

RFC 9594 не навязывает группам один способ защиты. Он задаёт интерфейс KDC, общие структуры CBOR, ошибки, media type и реестры IANA. Прикладной профиль обязан определить тип и кодирование ключей, идентификаторы, credentials, proof-of-possession, политики, защиту rekey, поддерживаемые ресурсы и возможности Клиента.

Значение ace_groupcomm_profile называет специализацию, но не выполняет её. Фраза «поддерживает RFC 9594» без названия профиля, параметров, проверок и установленной версии описывает только оболочку.

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

NUM+1 не появляется у всех одновременно

KDC обновляет материал при истечении срока и может делать это периодически. Обратная безопасность может потребовать новую эпоху при вступлении, чтобы новый участник не читал прошлое; прямая безопасность — при уходе или исключении, чтобы старое состояние не читало будущее.

Перед рассылкой KDC увеличивает NUM и распространяет NUM+1. Это может потребовать нескольких сообщений разным участникам. RFC 9594 прямо допускает временное рассогласование: часть группы уже обновилась, часть осталась на старом состоянии. После завершения KDC удаляет прежний материал и должен сохранять новый.

Здесь не повторяется отдельный тезис статьи RFC 9838 о последовательности KEK–TEK при исключении. Граница RFC 9594 общая: изменение версии внутри KDC не доказывает получение, проверку и активацию на каждом Клиенте. Эти переходы требуют отдельных квитанций.

Dispatcher доставляет, но не принимает в группу

Dispatcher раздаёт сообщения один-ко-многим. В multicast эта функция может быть неявной; в pub-sub или relay — явным посредником. Явный Dispatcher сравним с недоверенным узлом на пути: он видит защищённые сообщения и передаёт их, но не обладает групповыми ключами и не читает открытый текст.

Место в пути доставки не создаёт полномочий над членством. Broker может направлять сообщения узлам с разными num. Relay может зафиксировать отправку без доказательства приёма. Следующую границу — защищённое сообщение против локального действия — уже занимает статья RFC 10020. Этот материал заканчивается раньше: на доказательстве перехода от разрешения к членству и от членства к установленному состоянию.

Фиксировать переход, а не секрет

В журнале нужны ID или хэш токена, издатель, audience, scope, роли и срок; результат передачи KDC; транспортный профиль; ID защищённой связи; ID Join; GROUPNAME; NODENAME; прикладной профиль; num; проверки credentials и proof-of-possession; локальная установка; версия политик; начало и конец rekey; восстановление; последнее подтверждённое использование. Сам ключ журналировать нельзя.

AS свидетельствует о политике, KDC — о приёме и выдаче, Клиент — о проверке и установке, Dispatcher — о пересылке, приложение — о результате. Это дисциплина слоёв реальности Lu Heng: запись описывает решение, но не создаёт следующую операционную реальность. Переход подтверждает работающий код.

Источники