Resumo

  • O par pode conservar uma chave EAP ainda dentro do prazo enquanto o autenticador perde a entrada após reinício ou pressão de memória.
  • A RFC 5247 recomenda ressincronização protegida; sem uma chave comum capaz de proteger o reparo, a saída segura é uma nova autenticação, não a confiança no relógio antigo.

O recibo que existia só de um lado

Depois de acordar, um equipamento consulta seu cache: contexto encontrado, prazo restante de quinze minutos. A tentativa abreviada começa. No autenticador, a busca pelo mesmo nome retorna vazio. Uma atualização havia reiniciado o processo e reconstruído a tabela sem aquela entrada.

O painel chama isso de “chave válida recusada”. A descrição parece objetiva, mas empresta ao autenticador a memória observada apenas no par. A entrada local está dentro de sua janela; a entrada remota não existe. Validade e existência ocupam eixos diferentes.

A RFC 5247 formula esse limite diretamente. O par ou o autenticador pode reiniciar ou recuperar recursos, eliminando parte ou todo o cache. Logo, negociar duração não garante sincronismo. Às vezes o par só descobre se a chave está no autenticador quando tenta usá-la.

Um vencimento limita um objeto que continua presente. Não compra retenção em outra máquina.

O atalho preserva trabalho, não conclusões

O framework separa o método EAP, a troca AAA e o protocolo de associação segura. O método entre par e servidor pode exportar MSK, EMSK e identificadores. AAA pode levar material e autorizações ao autenticador. Na fase seguinte, o par e o autenticador escolhem o contexto, demonstram posse, negociam capacidades e estabelecem chaves transitórias.

Guardar material em cache evita repetir parte do custo. A nova sessão, porém, ainda precisa responder perguntas atuais. Os dois lados selecionaram a mesma chave? Ambos a possuem? O escopo permite este uso? As contribuições de frescor geraram TSKs novas? As chaves foram ativadas para o tráfego correto?

Um hit local preserva história. A prova mútua produz evidência presente. Confundir as duas coisas é transformar otimização em autoridade.

Selecionar K não prova possuir K

As mesmas partes podem compartilhar mais de uma chave do mesmo tipo. Por isso a RFC exige que o protocolo de associação nomeie explicitamente a chave usada na demonstração de posse. Uma correspondência por identidade ampla pode escolher a linha errada ou deixar cada lado em uma geração diferente.

O nome é coordenada, não credencial. Depois dele vem uma troca protegida que demonstra posse sem revelar o material. Em camadas que permitem cache, também é obrigatório gerar TSKs frescas, normalmente misturando nonces ou contadores. Reaproveitar diretamente a chave de tráfego anterior negaria a frescura que o atalho precisa preservar.

O registro operacional deve seguir a sequência: nome pedido, hit em cada lado, prova conjunta, entradas de frescor, derivação, ativação, pacote protegido e serviço observado. Se a sequência parar na busca, não há base para declarar senha errada, revogação ou ataque.

O pedido de conserto não pode autorizar a si mesmo

Ao detectar a divergência, alguém pode propor que o lado que ainda guarda a chave a reenvie. Mas instalar estado criptográfico é uma ação privilegiada. A mensagem de reparo precisa de uma raiz de confiança ainda disponível.

A RFC recomenda ressincronizar pelo protocolo de associação segura ou por indicação da camada inferior. Quando os dois lados ainda compartilham uma chave apta a proteger a conversa, essa chave sustenta o ajuste. Quando não compartilham, a ressincronização segura não é possível com base no estado perdido.

Uma mensagem aberta dizendo “eu conhecia K” não pode recriar a autoridade de K. O caminho correto é iniciar EAP novamente, inclusive após um temporizador quando adequado. A autenticação longa pode reavaliar identidade e autorização, produzir material novo e criar uma associação nova.

A latência é maior; a proveniência também é melhor. A recuperação não finge continuidade onde houve ruptura.

Escopo é uma segunda forma de divergência

Mesmo que os bytes estejam nos dois caches, o uso permitido pode não coincidir. A RFC 5247 recomenda sincronização do escopo para que cada parte entenda o cache da outra e negocie restrições de utilização.

Uma chave vinculada a um autenticador, porta, conjunto de serviço ou perfil de tráfego não ganha alcance novo por permanecer dentro do prazo. Em mobilidade, o caminho AAA pode ainda escolher outro servidor. Servidores do mesmo domínio podem validar a mesma credencial sem compartilhar todo o estado persistente.

Assim, uma retomada que falha pode indicar perda, seleção, escopo, rota de backend ou política. O protocolo fornece categorias; não fornece licença para atribuir culpa sem telemetria.

Não chamar todo miss de falha de identidade

Interfaces de suporte gostam de uma causa curta. “Credenciais inválidas” cabe no campo e transfere a ação ao usuário. Num cache distribuído, essa economia semântica pode ser destrutiva. Trocar a senha não recupera memória apagada; bloquear a conta não corrige um identificador de chave divergente.

Conserve a primeira fronteira sem recibo: nome desconhecido, contexto ausente, prova de posse falhou, TSK fresca não surgiu, ativação não confirmou, política negou ou tráfego protegido não encontrou serviço. Cada ponto possui dono e correção diferentes.

Quando a observação não distingue reinício de expulsão, marque a causa como desconhecida. A RFC descreve possibilidades arquitetônicas, não um incidente real nem o comportamento de um produto específico.

Apagar um lado de propósito

O teste revelador não reinicia tudo ao mesmo tempo. Ele exercita quatro quadrantes: ambos retêm; só o par retém; só o autenticador retém; nenhum retém. Em cada caso, verifique limite de tentativas, transição para EAP completo, emissão de material novo, ativação de TSK fresca e ausência de ressurreição silenciosa da chave antiga.

Depois, aumente a escala. Reinícios em lote e pressão de memória transformam muitos hits esperados em misses simultâneos. A economia do cache desloca capacidade para fora do caminho normal; se o caminho completo foi reduzido demais, a reconstrução vira indisponibilidade.

A pergunta de capacidade não é apenas quantas entradas cabem. É quantos misses seguros por segundo podem voltar à autenticação completa sem degradar prova, fila e serviço.

Sources