Resumo

  • O FRID é um NAI pseudônimo emitido pelo servidor para localizar um contexto EAP-IKEv2 anterior. Encontrar a linha correta não prova que quem apresentou o identificador possui as chaves daquele contexto.
  • A reconexão só termina depois que as mensagens 3 e 4 são protegidas e verificadas com o contexto anterior, SPI e nonces novos são usados e MSK/EMSK novos são derivados. Acesso e serviço permanecem resultados posteriores.

O painel registrou context found e coloriu a sessão de verde. A equipe de rede interpretou a cor como autenticação concluída. Horas depois, descobriu que o pacote seguinte falhara na verificação de integridade e que nenhum material novo de sessão havia sido exportado.

O RFC 5106 evita essa compressão. O EAP-IKEv2 usa mecanismos do IKEv2 para autenticação mútua e criação de chaves. Seu fast reconnect economiza trabalho quando servidor e par já compartilham um contexto criado por execução anterior bem-sucedida. A otimização não transforma um identificador em prova.

Na execução completa, o servidor EAP é o initiator e o par é o responder. Eles negociam algoritmos, produzem Ni e Nr, podem trocar material Diffie-Hellman e validam payloads AUTH protegidos. EAP-Success e a geração de MSK/EMSK só acontecem depois da autenticação das duas pontas.

O servidor pode incluir um Next Fast-ID no fluxo protegido. O NFID carrega um Fast-Reconnect-ID em formato NAI. O username é ofuscado; o realm continua visível para o roteamento AAA. O servidor cria o pseudônimo e mantém sua associação com a identidade permanente e o contexto de segurança.

Esse desenho dá ao FRID uma função precisa: localizar estado. Um componente aleatório fresco reduz colisão e correlação, mas o texto não se torna uma credencial autossuficiente. Uma pessoa que observa o valor ainda não possui as chaves antigas necessárias para construir ou verificar a reconexão.

O RFC também reconhece que um cluster pode receber o retorno em outro nó. Não existe garantia de que o mesmo servidor emissor será usado. Servidores do operador podem compartilhar um mecanismo central de mapeamento; sem ele, o nó que não entende o pseudônimo pode pedir a identidade permanente. unknown_frid pode ser falha de distribuição, não fraude.

O par só pode pedir fast reconnect se o último fluxo bem-sucedido lhe entregou o FRID em NFID. A resposta de identidade é obrigatória. Após o mapeamento, política local escolhe fast reconnect ou fluxo completo. O par deve suportar a resposta de fluxo completo mesmo tendo oferecido FRID.

Assim, apresentação, lookup e seleção de caminho são eventos separados. O painel que marca autenticação no lookup perde os casos em que política recusa o atalho, contexto está obsoleto ou as chaves das pontas divergiram.

As mensagens 3 e 4 executam a prova. Elas usam as chaves da execução anterior para cifrar e proteger integridade. O servidor escolhe SPI novo e não nulo na proposta, gera Ni fresco e, se desejar, KEi fresco. O par verifica a mensagem 3, escolhe seu SPI, gera Nr e protege a mensagem 4.

Somente depois de decifrar e validar corretamente a mensagem 4 o servidor considera a reconexão bem-sucedida e envia EAP-Success. Um hit perfeito no cache pode anteceder uma falha legítima de integridade. O banco respondeu qual contexto tentar; não respondeu se o par atual consegue usá-lo.

O sucesso inaugura uma nova geração. SKEYSEED combina SK_d antigo, os nonces e o segredo Diffie-Hellman opcional. As chaves específicas de EAP-IKEv2 são regeneradas. Dos 128 octetos de KEYMAT, os primeiros 64 formam MSK e os outros 64 EMSK. A especificação proíbe essa geração quando a execução não terminou com sucesso.

Session-ID incorpora o tipo do método e os Ni/Nr atuais. Peer-ID e Server-ID vêm do fluxo completo que criou o contexto. FRID, identidades autenticadas e sessão fresca são chaves de correlação diferentes. Um schema que as reduz a user_id elimina a genealogia do estado.

A emissão do próximo FRID também não é confirmação de armazenamento. O par pode falhar antes de persistir o NFID. O servidor deve conservar o FRID usado mais recentemente e o emitido mais recentemente. Se a autenticação falhar, não pode substituir o FRID da última autenticação bem-sucedida.

Essa regra impede que uma rotação incompleta destrua a última referência compartilhada. Em sistemas distribuídos, sent não equivale a committed. A transição bem-sucedida, não o timestamp mais novo, deve definir qual geração é recuperável.

Replay é avaliado contra a época de chaves. Depois de uma reconexão bem-sucedida, uma mensagem 3 antiga deve falhar porque as chaves mudaram. Para demonstrar isso, observabilidade precisa guardar geração de contexto, SPI, digests dos nonces e resultados das verificações. Repetição do FRID isolada não explica o evento.

EAP-Success termina o método, mas não conclui a rede. O RFC 5247 posiciona exportação de chaves numa arquitetura maior. AAA ainda autoriza o serviço; o authenticator recebe e instala material; o lower layer abre; o primeiro pacote protegido e o probe de serviço confirmam efeitos.

O RFC 5106 informa que channel binding não é suportado. Portanto o sucesso do método não prova todas as propriedades do acesso subjacente. Exibir “rede correta e utilizável” a partir de EAP-Success é adicionar uma afirmação que o protocolo não entregou.

A privacidade do pseudônimo tem escopo. Username é ocultado, realm não. Logs devem evitar FRID em claro e usar digest com período e generation quando correlação for necessária. O identificador de privacidade não deve virar rastreador permanente.

Também é preciso separar a história criptográfica da política atual. O mínimo de interoperabilidade de 2008 citava MODP 1024, 3DES e transformações da era SHA-1. Conformidade histórica não autoriza uso moderno. Suite negociada, política e exceção precisam de registros próprios.

Um modelo operacional útil guarda digest do FRID, realm, emissor, receptor, resultado de lookup, generation, decisão fast/full, SPI, digest de Ni/Nr, grupo DH, verificação de mensagens 3/4, Session-ID, resultado EAP e handles de chave. Depois associa decisão AAA, instalação, primeiro tráfego e teste de serviço.

Alertas passam a dizer onde o recibo sumiu: FRID desconhecido, generation divergente, integridade falhou, nonce repetiu, EAP terminou sem exportar, AAA autorizou sem instalar ou instalação não gerou tráfego. Cada evento aponta para um responsável e evita a conclusão vaga de que “a autenticação caiu”.

Fast reconnect é rápido porque reutiliza confiança anterior dentro de um novo intercâmbio protegido. Não é rápido porque o software decidiu confiar no nome que encontrou uma linha de cache.

Expiração merece um evento próprio. O mesmo not found pode esconder uma tabela não replicada, um contexto removido por memória, uma política que encerrou a geração ou uma revogação deliberada. Essas causas têm respostas diferentes: tentar outro servidor, executar fluxo completo, investigar churn ou bloquear uma credencial. Apagar o motivo junto com a linha obriga o cliente a adivinhar.

Também não é seguro recriar um contexto vazio porque o FRID continua conhecido. Sem as chaves antigas, a identidade original e o último commit bem-sucedido, a nova linha compartilha apenas um nome. O caminho correto é voltar ao fluxo completo e criar uma nova raiz autenticada, não simular continuidade administrativa.

Métricas de desempenho devem acompanhar identity_to_lookup, lookup_to_message3, message3_to_message4 e message4_to_success. Um cache mais rápido pode reduzir o primeiro número enquanto context drift aumenta os demais. Latência de lookup não representa latência de uma sessão comprovada.

Retries precisam de attempt ID. O mesmo FRID pode aparecer numa retransmissão causada por perda e numa nova tentativa contra outra generation. SPI, Ni, contexto e bytes da mensagem permitem a separação. Deduplicar apenas pelo pseudônimo pode bloquear recuperação normal; nunca deduplicar por generation pode esconder replay.

Fontes