Resumo

  • Na RFC 9594, o Servidor de Autorização permite que um Cliente acesse um recurso de associação; o KDC ainda precisa validar o Join e devolver o material definido pelo perfil de aplicação.
  • Token emitido, membro registrado, versão instalada e operação de grupo bem-sucedida são fatos separados e exigem recibos de componentes diferentes.

Um dispositivo recebe um token assinado, com escopo correto e validade restante. A tela de identidade fica verde. Nada disso demonstra que o dispositivo já seja membro do grupo. Ele pode nem ter apresentado o token ao KDC; a associação segura pode falhar; o pedido Join pode ser recusado; a resposta pode chegar e não ser instalada.

A RFC 9594 não trata essas possibilidades como detalhes posteriores. Ela organiza o protocolo ao redor delas. A primeira fase segue o arcabouço ACE entre Cliente, Servidor de Autorização e KDC, que atua como Resource Server. A segunda é a distribuição efetiva do material de chaves entre Cliente e KDC. Permissão para solicitar e estado operacional adquirido são eventos distintos.

A autoridade de política termina antes do Join

O Servidor de Autorização decide se o Cliente pode acessar um ou mais recursos de associação e quais papéis pode pedir. O token é transferido ao KDC, em geral por /authz-info, e a comunicação Cliente–KDC segue um perfil de transporte ACE, como DTLS ou OSCORE.

O ingresso começa depois, com uma requisição para /ace-group/GROUPNAME. O KDC compara grupo, escopo e papéis com a autorização armazenada e executa as verificações da especificação-base e do perfil de aplicação. Somente a resposta Join bem-sucedida acrescenta o Cliente ao conjunto atual de membros e devolve o material necessário.

Isso limita corretamente o significado do token. Ele não prova que chegou ao KDC, que o canal seguro permaneceu válido, que houve Join, que os papéis coincidiram, que uma credencial ou prova de posse foi aceita, que um recurso de nó foi criado ou que o Cliente ativou a resposta.

Nome estável não é chave atual

GROUPNAME identifica o recurso de associação e permanece invariável depois de criado. O nome do nó e o componente NODENAME também são invariáveis e únicos entre os nós atuais. A estabilidade mantém endereços e referências administráveis.

O estado criptográfico gira. num informa a versão atual do material de grupo. Identificadores, material individual, credenciais dos pares e políticas precisam ser interpretados segundo o perfil e a versão. Dois Clientes podem apontar para o mesmo grupo e manter, temporariamente, épocas incompatíveis.

O erratum técnico 8239 do RFC Editor adiciona o num obrigatório a um exemplo de recuperação de credenciais que o omitia. O erratum 8864 corrige a descrição de filtros vazios. Ambos permaneciam reportados durante a pesquisa; não constituem prova de falha em produto. Mostram, porém, que uma lista de credenciais sem versão não reconstitui o estado operacional.

O perfil de aplicação conclui a especificação

A RFC 9594 não escolhe um único mecanismo de segurança para todos os grupos. Ela padroniza a interface do KDC, estruturas CBOR, erros, tipo de mídia e registros extensíveis. O perfil de aplicação deve definir tipo e formato de chave, identificadores, representação de credenciais, prova de posse, políticas, proteção de rekey, recursos oferecidos e capacidades mínimas do Cliente.

O valor ace_groupcomm_profile identifica a especialização. Não a implementa. Uma afirmação de compatibilidade que omite o perfil concreto, seus parâmetros e verificações só nomeia a moldura.

Esse desenho combina com a especificação inicial mínima: o plano comum contém o necessário para coordenação, enquanto escolhas especializadas permanecem locais, explícitas e testáveis. O perigo aparece quando o rótulo do RFC encobre essas escolhas e passa a prometer um comportamento que a base delegou.

O NUM avança antes de todos os membros

O KDC renova material expirado e pode fazê-lo periodicamente. Conforme a política ou o perfil, uma entrada pode exigir segurança retroativa e uma saída ou expulsão pode exigir segurança futura. Antes de distribuir o novo material, o KDC incrementa NUM e envia NUM+1.

A distribuição pode usar várias mensagens. A RFC 9594 reconhece o desalinhamento temporário: parte do grupo já guarda a nova versão enquanto outra parte continua na antiga. Depois da conclusão, o KDC elimina o material anterior e deve persistir o novo.

Este texto não repete o mecanismo KEK–TEK de exclusão pertencente ao artigo sobre RFC 9838. A fronteira própria aqui é mais geral: um incremento dentro do KDC não comprova recebimento, verificação e ativação em todos os Clientes. Esses fatos precisam de recibos separados.

O Dispatcher entrega, mas não admite

O Dispatcher distribui mensagens um-para-muitos. Pode ser implícito no multicast ou explícito como broker e relay. Quando explícito, funciona como intermediário não confiável no caminho: vê mensagens protegidas e as encaminha, mas não possui o material do grupo nem lê o conteúdo em claro.

Logo, posição no transporte não vira autoridade sobre membros. Um broker pode encaminhar para destinos com num diferentes. Um relay pode observar envio sem comprovar aceitação. A fronteira posterior entre mensagem protegida e ação local já pertence ao artigo sobre RFC 10020. Aqui a investigação termina na passagem de autorização para associação e de associação para estado instalado.

Registre a transição, nunca o segredo

O ledger de auditoria deve guardar identificador ou hash do token, emissor, audiência, escopo, papéis e expiração; resultado da transferência ao KDC; perfil de transporte; identidade da associação segura; identificador do Join; GROUPNAME; NODENAME; perfil de aplicação; num; verificações de credenciais e prova de posse; instalação local; versão de políticas; início e fim do rekey; recuperação; e último uso confirmado. Não deve armazenar a chave.

Cada ator responde pelo que observa. O AS atesta sua decisão. O KDC atesta admissão e distribuição. O Cliente atesta verificação e instalação. O Dispatcher atesta encaminhamento. A aplicação atesta o efeito. Essa é a disciplina das camadas de realidade de Lu Heng: um registro descreve uma decisão, mas não cria o estado seguinte; código em execução continua sendo a prova da transição.

Fontes