Кратко

  • RFC 10020 отдельно определяет группу CoAP, прикладную группу и группу безопасности. Между ними допустимы связи многие-ко-многим, один-ко-многим, многие-к-одному и один-к-одному; их соответствие задаёт конкретное внедрение.
  • Group OSCORE позволяет установить конкретного участника группы безопасности, создавшего защищённое сообщение. Сам RFC отделяет это доказательство от допуска к прикладному ресурсу и не рекомендует использовать членство как замену контролю доступа.

Устройство уже вывели из обслуживаемой зоны, но оно по-прежнему слушало прежний multicast-адрес. На нём оставался тот же путь CoAP. Переиздание групповых ключей ещё не завершилось. Поэтому очередная команда пришла в корректной защите, подпись была действительной, а отправитель — известным.

Система надёжно доказала автора пакета. Она не могла тем самым доказать, что этот автор всё ещё вправе управлять данным ресурсом.

Именно такую границу проводит RFC 10020 — документ IETF Standards Track о групповой связи CoAP, опубликованный в июле 2026 года. Он отменяет RFC 7390, обновляет RFC 7252 и RFC 7641, а транспортом групповых запросов по умолчанию назначает UDP/IP multicast. Для управления важнее другое: стандарт не превращает все значения слова «участник» в одно полномочие.

Адрес, функция и защитный контекст

Группа CoAP — это конечные точки, настроенные принимать групповые сообщения по связанным IP multicast-адресу и UDP-порту. Она отвечает на сетевой вопрос: кто слушает это назначение? В групповом URI можно указать адрес или групповое имя хоста и, при необходимости, порт вместо стандартного CoAP-порта 5683.

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

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

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

Список отправителей тоже не следует из списка слушателей. В область стандарта входит Any-Source Multicast: источник может входить или не входить в целевую IP-группу, а число источников модель не ограничивает. Интерфейс, объявляющий каждого слушателя разрешённым отправителем, добавляет политику, которой в транспорте нет.

Аутентификация не доходит до решения о ресурсе

Защищённая групповая связь использует Group OSCORE из RFC 10021. Он развивает OSCORE из RFC 8613 и применяет структуры COSE, включая описанные в RFC 9052, для защиты CoAP на прикладном уровне. В групповом режиме отправитель подписывает сообщение собственным закрытым ключом; в попарном режиме выводятся ключи для обмена один-к-одному.

Получатель приобретает сильное, но ограниченное доказательство. Он проверяет, что сообщение создала определённая, идентифицируемая конечная точка — участник группы OSCORE. Общий симметричный материал сам по себе дал бы лишь аутентификацию на уровне группы; Group OSCORE добавляет аутентификацию источника. Но он не удостоверяет исходный IP-адрес или UDP-порт пакета.

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

Следовательно, удачная проверка подписи отвечает: кто отправил запрос в эту эпоху ключей? Авторизация отвечает: может ли эта личность сейчас применить этот метод к этому пути в данном прикладном контексте? Если первую отметку перенести во второе поле, распределение ключей незаметно становится системой выдачи привилегий.

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

Реестры создаются разными сторонами и в разное время

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

Документ отмечает, что разные стороны способны выполнять эти этапы почти без координации или вовсе без неё. Завод закладывает защитную личность, интегратор выбирает адрес и порт, облачная служба определяет ресурсы, а ремонтная команда позднее меняет только один слой. Рассинхронизация возникает без атаки — достаточно независимых календарей.

Обслуживание охватывает добавление и удаление участников, смену защитного материала, адреса или UDP-порта, изменение URI, переименование прикладных групп, их разделение и объединение. Запись «устройство удалено из группы» непригодна для аудита, если не названы группа, эпоха и проверка двух остальных реестров.

У ключей есть собственное время. Группы OSCORE должны применять rekeying для безопасного отзыва и обновления. При частой смене состава и медленной операции Group Manager может осторожно объединить несколько изменений. Компромисс известен: до завершения ушедший участник способен сохранять доступ с прежним материалом; в зависимости от политики новый участник может получить доступ к прошлому трафику.

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

Молчание не доказывает отсутствия выполнения

Клиент отправляет групповой запрос по multicast, а отдельные серверы обычно отвечают по unicast. Чтобы ограничить перегрузку и шквал ответов, запросы отправляются как Non-confirmable, а серверы распределяют ответы по случайному интервалу Leisure. Ограничения NSTART и PROBING_RATE сохраняются.

Сервер может подавить ответ. RFC 10020 рекомендует поступать так при ошибке или отсутствии полезного содержания, если только политика приложения не требует ответа от конкретного ресурса. Опция No-Response должна влиять на правило лишь там, где это заранее признано подходящим.

Молчание может означать потерю запроса, отсутствие подходящего ресурса, подавленный отказ, ожидание Leisure, потерю ответа либо выполнение без ответа. Повтор с новым Message ID может снова запустить обработку на серверах, уже выполнивших первую копию. Число полученных ответов не равно числу действий.

В этом проявляется принцип Heng Lu о приоритете работающего кода. Конфигурация описывает ожидаемые адреса, функции и защитное участие. Наблюдение описывает поведение внедрения. Контроль соединяет замысел и результат, не выдавая один за другой.

Квитанция трёх реестров

Квитанция трёх реестров авторизации сохраняет всю цепочку. Первый раздел описывает группу CoAP: multicast-адрес или имя, UDP-порт, область адреса, слушающие точки, источник обнаружения и эпоху конфигурации. Отправитель записывается отдельно, поскольку Any-Source Multicast не требует от него членства среди слушателей.

Второй раздел описывает прикладную группу и решение по ресурсу: URI-путь, метод, класс данных, ожидаемые серверы, версию политики, проверенную учётную запись или свойство ресурса, результат и срок действия. Формулировка «подпись верна» не может заполнять поле допуска.

Третий раздел описывает группу безопасности: Group Manager, идентификатор, алгоритмы, аутентифицированного отправителя, эпоху OSCORE, доказательство вступления, состояние выхода, последнее переиздание ключей и полноту его завершения. Аутентификация отправителя отделяется от проверки сетевого адреса. Когда требуется подтвердить достижимость заявленного источника, Echo из RFC 9175 помогает проверить, доступен ли аутентифицированный клиент по этому адресу.

В разделе результата остаются ожидаемые получатели, наблюдаемая обработка, политика подавления, окно Leisure, ответы, известные потери, повторы и побочные эффекты. Молчание хранится как неопределённость, а не превращается в «не выполнено». Каждое изменение реестра связывается с его исполнителем и последующей сверкой двух других.

Эта квитанция — редакционное предложение Daniel Kade, а не требование RFC 10020. Она не даёт действительному адресу, существующему ресурсу и текущему ключу слиться в один зелёный индикатор, который ничего не говорит об authority.

Защита сужает усиление, но не отменяет множитель

RFC 10020 настоятельно не рекомендует NoSec. Исключения ограничены узкими, хорошо понятыми этапами, которые не требуют защиты или ещё не могут её получить, например отдельным ранним обнаружением. Групповой сервер NoSec не должен быть доступен из публичного интернета. Один multicast-запрос с поддельным адресом источника способен направить ответы нескольких серверов на жертву.

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

Идея Heng Lu о зеркале политики предлагает правильный интерфейс: отражать реальное распределение контроля. Адрес, ресурс, Group Manager, авторизация, подавление и наблюдение принадлежат разным сторонам. Надпись «группа защищена» не сообщает, какая из них выполнила обязательство.

Ориентация BTW Media на реальность требует точного доверия. Адрес удостоверяет настроенное назначение. Group OSCORE удостоверяет личность в эпоху ключей. Авторизация удостоверяет право на ресурс. Операционные данные удостоверяют результат. Сохраняя границы, система сохраняет ответственность.

Источники