Resumo

  • No fluxo básico de controle de acesso futuro da RFC 9838, a mudança de membros estabelece primeiro uma KEK nova; outro rekey entrega depois a política e as chaves TEK sob essa nova KEK.
  • O GSA_REKEY multicast não é confirmado e pode se perder. Cópias cifradas idênticas e GSA_NEXT_SPI ajudam na recuperação, mas não produzem uma prova de instalação por membro.
  • ATD posterga o uso das novas SAs; DTD posterga a exclusão das antigas. O prazo real de exclusão atravessa essa sobreposição e não cabe num único horário do sistema de identidade.

O cadastro concluiu a baixa. A criptografia ainda precisava tornar verdadeira a consequência dessa decisão em todos os pontos relevantes.

A RFC 9838 padroniza o Group Key Management Using IKEv2, ou G-IKEv2. O registro oficial informa publicação em novembro de 2025, Standards Track e substituição da RFC 6407. O status valida uma especificação comum, não a exclusão de um equipamento real.

O protocolo se apoia na arquitetura MSEC de RFC 3740, RFC 4046 e RFC 5374. O GCKS autentica e autoriza membros e distribui a Group Security Association com políticas e chaves para Data-Security SAs e, quando usada, a Rekey SA multicast.

Registro e rekey cumprem papéis distintos. IKEv2 estabelece a relação bilateral; a arquitetura IPsec, AH e ESP definem associações e proteção de pacotes. G-IKEv2 precisa levar essa disciplina a um conjunto de receptores que não responde como uma sessão única.

A primeira troca ainda é legível pelo grupo antigo

Controle de acesso futuro significa impedir que o membro removido obtenha uma chave nova. Controle retroativo impede que o recém-admitido obtenha a antiga. A RFC separa essas propriedades da Perfect Forward Secrecy de IKEv2.

O rekey que altera a composição é protegido pela KEK corrente. Se ele também carregasse a nova política TEK e suas chaves, o membro em saída conseguiria lê-las. Quando o controle futuro é exigido, esse primeiro rekey não pode incluir TEK novo. Um segundo pode entregar o material, porque já está sob a KEK nova.

Se até a política alterada precisar ficar oculta, o GCKS envia dois rekeys sequenciais, ambos mudando a KEK. O primeiro cria uma KEK fora do alcance do excluído; o segundo muda de novo a KEK e leva a política. A política não pode mudar sem uma KEK nova.

O requisito não é imutável para todos os algoritmos. Métodos futuros podem realizar a propriedade em uma mensagem se especificarem como a preservam. A hierarquia lógica de RFC 2627 fornece o contexto. Para a sequência básica atual, porém, um indicador “removido” não representa as duas fronteiras criptográficas.

Multicast registra envio, não consenso

O GCKS pode usar rekey unicast em banda ou GSA_REKEY multicast. O segundo é unilateral e não confirmado. Um membro legítimo pode perder a mensagem e permanecer no estado anterior.

Para reduzir a perda, o servidor pode repetir em poucos segundos a mesma mensagem cifrada, idêntica bit a bit. Pode também anunciar SPIs futuros por GSA_NEXT_SPI, permitindo que um receptor perceba um salto e se recupere. A repetição melhora a chance; não revela o estado instalado de quem ficou silencioso.

A fragmentação mostra a mesma limitação. Com RFC 7383, o multicast não pode testar primeiro uma mensagem inteira nem medir PMTU aguardando resposta. O limiar é preconfigurado. Grupos maiores e hierarquias mais extensas podem tornar a própria entrega do rekey uma parte crítica do objetivo de exclusão.

A disponibilidade mantém duas gerações por algum tempo

ATD é a espera antes de emissores usarem novas SAs. DTD é a espera antes de os membros apagarem SAs antigas. Essa convivência evita um corte brusco, mas cria uma faixa na qual autorização, instalação e comportamento de tráfego contam histórias diferentes.

O recibo adequado identifica quando a autorização cessou, a KEK nova surgiu, a TEK nova foi instalada, a SA nova entrou em uso e a antiga desapareceu. Um teste com a credencial removida delimita até quando o efeito antigo persistiu.

Modos de contador acrescentam Sender-ID e nonces. Com base na RFC 6054, cada emissor recebe identificação exclusiva e nova identificação a cada registro, pois o GCKS não sabe com segurança quais nonces já foram usados. Ao esgotar o contador, o servidor precisa excluir todos e exigir novo registro e novas Data-Security SAs. RFC 8221 e RFC 8750 dão contexto algorítmico, não eliminam o livro operacional.

O anti-replay também é local. Muitos emissores numa mesma SA avançam sequências independentemente; um receptor pode não conseguir manter uma janela coerente. Ele decide se faz a checagem, e o GCKS pode separar emissores em SAs quando a proteção justificar o custo.

O registro IANA de IKEv2 documenta valores, RFC 8174 explica a força de MUST e RFC 6407 registra o antecessor. Nenhum deles observa o endpoint.

A tese de Heng Lu sobre especificação mínima e decisão futura localizada deixa o padrão definir a semântica e o operador definir o prazo que consegue provar. A primazia do código em execução exige estado instalado e tráfego observado. O princípio de realidade, não defesa institucional impede que Standards Track seja confundido com garantia operacional.

Fontes