Resumo

  • O RFC 10020 define grupos CoAP, grupos de aplicação e grupos de segurança como conjuntos diferentes. Eles podem se relacionar de muitos para muitos, um para muitos, muitos para um ou um para um, conforme a configuração do ambiente.
  • O Group OSCORE identifica o membro específico do grupo de segurança que originou uma mensagem protegida. O RFC separa essa prova da autorização para usar recursos da aplicação e recomenda que a participação no grupo não substitua o controle de acesso.

O equipamento ainda recebia comandos destinados a um setor que já não integrava. A escuta no endereço multicast permanecia ativa. O recurso CoAP seguia no mesmo caminho. O material do grupo de segurança ainda não tinha sido renovado. Assim, o comando chegou protegido, com assinatura válida e remetente identificável.

Todas as respostas técnicas podiam ser verdadeiras e, mesmo assim, faltar a resposta institucional: aquele remetente ainda podia exercer aquela ação sobre aquele recurso?

Essa pergunta decorre da distinção feita pelo RFC 10020, documento IETF Standards Track de julho de 2026 para comunicação em grupo no CoAP. A especificação substitui o RFC 7390, atualiza o RFC 7252 e o RFC 7641, e adota multicast UDP/IP como transporte padrão das requisições coletivas. Seu mérito para a governança é não transformar todas as acepções de pertencimento em um único estado.

Alcançar, servir e autenticar

Um grupo CoAP é formado por endpoints configurados para receber mensagens enviadas ao endereço IP multicast e à porta UDP do grupo. É uma lista de alcance de rede: informa quais endpoints escutam naquele destino. A URI pode conter o endereço ou um hostname de grupo e indicar uma porta diferente da porta CoAP 5683.

Um grupo de aplicação reúne servidores que compartilham funcionalidade por meio de recursos CoAP. É uma lista funcional: informa quais servidores devem interpretar determinado método e caminho como parte daquela aplicação. O nome pode ser declarado no caminho da URI ou inferido pela mensagem e pelo contexto.

Um grupo de segurança reúne endpoints que armazenam material compartilhado para proteger e verificar as mensagens. É uma lista de participação criptográfica: informa quem consegue produzir ou processar comunicação válida nesse contexto. Um mesmo endpoint pode entrar em vários grupos de segurança.

O RFC 10020 permite relações muitos-para-muitos, um-para-muitos, muitos-para-um e um-para-um entre essas listas. Vários grupos de aplicação podem aproveitar um grupo de segurança para reduzir armazenamento e atualizações. Uma aplicação pode usar diversos grupos de segurança para atender clientes com algoritmos incompatíveis. A entidade configuradora escolhe as associações para o seu ambiente.

Nem mesmo a lista de remetentes se confunde com a de ouvintes. O escopo é Any-Source Multicast: a origem pode ou não integrar o grupo IP de destino e não existe restrição intrínseca ao número de origens. Uma ferramenta que chama todo ouvinte de “emissor permitido” inventa uma regra que o transporte não contém.

Autenticar a origem não autoriza o recurso

A comunicação protegida usa Group OSCORE, especificado no RFC 10021. Ele estende o OSCORE do RFC 8613 e utiliza estruturas COSE, como as do RFC 9052, para proteger mensagens CoAP na camada de aplicação. O modo de grupo usa a assinatura privada de cada origem; o modo pairwise deriva chaves para trocas individuais.

O resultado é uma garantia forte e delimitada. O destinatário consegue verificar que a mensagem foi originada por um endpoint específico, identificável e membro do grupo OSCORE. O material simétrico comum ofereceria apenas autenticação coletiva; o Group OSCORE acrescenta autenticação de origem. Ele não autentica, porém, o endereço IP e a porta de origem do pacote.

Também não concede licença geral para os recursos. O RFC 10020 afirma que diferentes grupos de segurança não devem representar políticas de acesso dentro do mesmo grupo de aplicação. A participação permite trocar mensagens protegidas e autenticar integrantes. Autorizar o uso de recursos pertence a outro domínio de segurança e deve empregar propriedades do recurso ou credenciais dedicadas.

São decisões sucessivas. A verificação diz quem enviou a requisição nesta época de chaves. A autorização diz se essa identidade pode aplicar este método a este caminho, neste escopo e agora. Usar a primeira como atalho para a segunda converte distribuição de material criptográfico em concessão de privilégio sem que ninguém tenha assumido essa decisão.

O ACE do RFC 9200 pode apoiar a autorização de um endpoint que pede ingresso ao Group Manager. Ainda assim, o direito de obter material do grupo não equivale ao direito de usar todo recurso protegido por ele. Admissão, autenticidade e operação precisam de evidências próprias.

Cadastros envelhecem em ritmos diferentes

O RFC 10020 fala em “entidade configuradora” porque os três grupos podem nascer sob administrações distintas. Uma aplicação, uma pessoa usuária, um desenvolvedor, um serviço em nuvem ou uma ferramenta de comissionamento podem criar e alterar grupos. A configuração pode acontecer durante a criação do produto, na fábrica, no revendedor, na primeira instalação ou numa reconfiguração em campo.

O texto reconhece que atores diferentes podem realizar essas etapas com coordenação mínima ou inexistente. A fábrica insere uma identidade; o integrador escolhe endereço e porta; a aplicação em nuvem define o conjunto de recursos; a manutenção posterior retira o equipamento de apenas um deles. Não é preciso um invasor para produzir desalinhamento.

Manutenção abrange entrada e saída de membros, troca de material de segurança, mudança de endereço IP multicast ou porta UDP, alteração da URI, renomeação, divisão e fusão de grupos. “Removido do grupo” é uma anotação insuficiente se não disser de qual lista, em que momento e quem conciliou as demais.

O estado das chaves também tem época. Grupos OSCORE precisam adotar rekeying para renovação e revogação seguras. Se as entradas e saídas forem frequentes e a atualização demorar, o Group Manager pode agrupar mudanças de modo cauteloso. O ganho operacional traz uma exposição: até o rekey terminar, quem saiu pode continuar acessando tráfego com o material antigo; conforme a política, um novo membro pode alcançar comunicações anteriores.

Por isso, o rótulo “membro do grupo de segurança” precisa vir acompanhado da época, do instante de saída e da conclusão da rotação. Sem esse tempo, um membro atual e um ex-membro ainda não revogado aparecem com a mesma capacidade.

Silêncio não comprova ausência de efeito

Uma requisição é enviada por multicast, mas cada servidor normalmente responde por unicast. Para evitar congestionamento e uma explosão de respostas, a requisição coletiva é Non-confirmable e os servidores distribuem os retornos num intervalo aleatório chamado Leisure. NSTART e PROBING_RATE continuam limitando a emissão.

Há também supressão. O RFC recomenda que o servidor deixe de responder em caso de erro ou quando não houver conteúdo útil, salvo se a política da aplicação exigir resposta para aquele recurso. A opção No-Response só deve influenciar esse padrão nos recursos em que tal influência foi previamente avaliada como adequada.

Logo, silêncio pode significar perda da requisição, recurso não aplicável, rejeição suprimida, espera em Leisure, resposta perdida ou execução sem retorno. Uma repetição com novo Message ID pode fazer quem processou a primeira requisição processar também a segunda. Contar respostas não revela automaticamente quantos efeitos ocorreram.

A defesa de Heng Lu pela primazia do código em operação oferece o método: configuração e execução devem ser comparadas. As três listas descrevem a arquitetura desejada; a observação registra o que os dispositivos fizeram. Nenhuma delas é prova completa isoladamente.

Um recibo de autorização de três cadastros

Um recibo de autorização de três cadastros pode unir as provas sem apagar seus limites. A primeira seção identifica grupo CoAP, endereço ou hostname multicast, porta UDP, escopo, endpoints ouvintes, fonte de descoberta e época de configuração. O remetente fica em campo separado porque Any-Source Multicast não exige que ele seja ouvinte.

A segunda seção identifica grupo de aplicação e decisão do recurso: caminho URI, método, classe de payload, servidores que deveriam oferecer a função, versão da política, propriedade ou credencial avaliada, resultado e validade. “Assinatura correta” nunca preenche o campo de autorização.

A terceira seção identifica o grupo de segurança: Group Manager, identificador, algoritmos, remetente autenticado, época OSCORE, prova de entrada, estado de saída, último rekey e alcance de conclusão. Autenticação do remetente e validação do endereço de rede permanecem separadas. Quando a origem alegada precisa ser validada, a opção Echo do RFC 9175 ajuda a comprovar que o solicitante autenticado está alcançável naquele endereço.

A seção de resultado registra destinatários esperados, processamentos observados, política de supressão, janela Leisure, respostas, perdas conhecidas, repetições e efeitos. Silêncio continua sendo incerteza. A seção de ciclo de vida liga cada mudança à entidade que a executou e à conciliação das outras listas.

Esse recibo é uma proposta editorial de governança de Daniel Kade, não uma exigência do RFC 10020. Ele evita que endereço válido, recurso presente e chave corrente virem um único indicador verde incapaz de explicar a autoridade.

O multiplicador permanece parte do risco

O RFC 10020 desaconselha fortemente o NoSec e limita qualquer exceção a etapas estreitas e bem compreendidas, como certas descobertas iniciais que não podem ou não precisam de proteção. Um servidor de grupo em NoSec não deve estar acessível pela Internet pública. Uma origem falsificada numa única requisição multicast pode induzir vários servidores a responder à vítima.

Group OSCORE reduz essa superfície ao autenticar o remetente e proteger caminho e consulta. Limites de resposta e a opção Echo reforçam a mitigação. Eles não eliminam um integrante malicioso, um adversário no caminho nem o volume produzido por respostas legítimas permitidas.

O espelho de políticas de Heng Lu sugere uma interface que reflita a distribuição real de controle. Endereço, recurso, Group Manager, autorização, supressão e telemetria têm responsáveis diferentes. “Grupo seguro” não esclarece qual deles cumpriu seu papel.

O compromisso da BTW Media com a realidade conduz a uma confiança mais precisa. O endereço prova o destino configurado. Group OSCORE prova uma identidade naquela época. A autorização prova a permissão sobre o recurso. A operação prova o resultado. Preservar os quatro nomes é preservar a prestação de contas.

Fontes