Resumo

  • Na RFC 9986, o receptor compara uma Auth Key de 32 bits derivada de uma sequência ISAAC com chave. A igualdade pode indicar conhecimento do segredo e posição aceitável, mas não autentica os outros campos do pacote.
  • A prova precisa preservar build, discriminators, época da chave, seed, janela, estado das páginas ISAAC, comparação e reautenticação MCI posterior. Não equivale a saúde de rota ou resultado de serviço.

O runbook dizia que, se o valor recebido fosse igual ao calculado, o pacote estava autenticado. A implementação obedecia à comparação da RFC 9986; a frase do runbook é que excedia o mecanismo. Ela transformava uma saída de 32 bits em garantia sobre dados que nunca entraram no cálculo.

O exemplo é construído e não descreve fornecedor, rede ou incidente. RFC 9986 define Meticulous Keyed ISAAC como mecanismo LCI para a arquitetura da RFC 9985. Também afirma que os pacotes desse formato não são assinados nem autenticados como pacotes e não podem sinalizar mudança de estado.

A pergunta verificável é menor: o par conseguiu reproduzir a saída esperada usando segredo compartilhado, valores da sessão BFD, seed e uma posição permitida da sequência? Um match sinaliza conhecimento e sincronização. Não vincula Diagnostic, State, flags, tempos, discriminators e demais campos a um autenticador criptográfico.

Auth Key e Authentication Section são nomes de função, não mapas de cobertura. Uma auditoria séria lista as entradas da derivação e os bytes que ficaram fora, em vez de ampliar a garantia pela terminologia.

A seção leva tipo, comprimento, Key ID, seed, deslocamento de sequência e Auth Key de 32 bits. O receptor seleciona a chave, confere o seed, procura uma posição na janela e deriva o candidato. A igualdade satisfaz o teste LCI especificado. Nenhum MAC abrange o corpo inteiro.

O contraste com RFC 8439 organiza o vocabulário. Em AEAD, uma tag autentica ciphertext e dados associados. Não é uma recomendação de algoritmo para BFD; é a diferença entre validar conteúdo ligado a uma tag e comparar uma única saída pseudorrandômica.

ISAAC torna a prova dependente de estado. Ele produz páginas e avança de forma destrutiva. Para tolerar perda, atraso e reordenação dentro da janela, o receptor pode calcular uma página futura. A RFC exige salvar e restaurar o estado nessa busca. Se a consulta mover o gerador ativo, o próximo pacote legítimo pode falhar e a decisão anterior não poderá ser reproduzida.

O seed marca uma época. Cada transição para Up exige um seed novo; durante essa época Up ele permanece fixo. Um log que guarde apenas Key ID e match elimina a posição que dá sentido ao resultado. Seed, época Up, número de sequência e regra da janela formam uma unidade. O segredo continua protegido, mas a época de provisionamento e rotação pode ser registrada.

O reuso limitado de chave não elimina governança. Entradas de sessão diferenciam saídas, porém uma chave cobrindo muitas sessões amplia o impacto de vazamento, rotação incompleta ou perda de registros. Revise população, entradas de derivação, proprietário e validade de cada época, não apenas a caixa “ISAAC habilitado”.

A página do RFC Editor classifica o texto como Experimental. Menor custo vem com menor segurança; ISAAC é descrito como, no máximo, tolerável nesse uso, com criptoanálise limitada e sem prova, e inadequado para outros protocolos IETF. O estudo IACR sustenta cautela, não a alegação de ataque contra uma implantação RFC 9986.

Também não há certificado geral de interoperabilidade. A RFC 9986 serve à construção específica de RFC 9985 e não deve ser presumida interoperável com a autenticação comum de RFC 5880. IANA BFD Parameters registra valores, não implementação, adoção ou sucesso operacional.

RFC 5881 limita BFD a um caminho de encaminhamento de um salto. RFC 7419, RFC 8177 e RFC 9127 dão contexto criptográfico. Nenhuma eleva LCI a prova de rota selecionada, transação de aplicação ou experiência do cliente.

A reautenticação MCI periódica da RFC 9985 é controle separado. Ela pode limitar a duração de um Up inadequado conforme o intervalo, mas não autentica retroativamente o conteúdo dos pacotes ISAAC intermediários. Os eventos devem ser correlacionados sem receber o mesmo significado.

As camadas de realidade de Heng Lu separam padrão, capacidade, configuração, Auth Key observada, estado BFD, reação do cliente e serviço. Running-Code Primacy põe comportamento observado antes do rótulo RFC. Minimum Initial Specification preserva um recibo comum estreito e deixa a decisão posterior ao operador responsável.

O recibo traz RFC e errata, build, discriminators, Key ID, época de chave, seed e época Up, posições enviadas e aceitas, janela, página ISAAC, save/restore, resultado, campos sem proteção, MCI, reação, dono da decisão e rollback. Deve permitir repetição da lógica sem expor o segredo.

O match é evidência útil quando continua do tamanho do que foi medido.

Fontes