Resumo

  • A RFC 3012 permitiu que o agente estrangeiro de Mobile IPv4 emitisse seu próprio desafio e rejeitasse valores ausentes, já usados ou fora da janela recente antes de a autenticação AAA terminar.
  • Devolver o desafio correto era só evidência local de frescor; ainda eram necessários vínculo criptográfico, decisão remota, aceitação do registro, encaminhamento e tráfego comprovado.

Roaming distribuía conhecimento de forma desconfortável. O nó móvel estava diante da rede visitada, mas o segredo capaz de validá-lo podia permanecer em casa. O agente estrangeiro precisava processar a Registration Request sem necessariamente compartilhar uma security association com aquele dispositivo.

Mandar tudo para um sistema remoto não resolvia o primeiro instante. Uma mensagem antiga podia ser repetida enquanto Authentication, Authorization and Accounting ainda buscava credenciais e política. O agente estrangeiro precisava de uma referência originada em seu próprio domínio operacional.

Publicada em novembro de 2000, a RFC 3012 criou essa referência. O agente estrangeiro inseria uma Challenge extension no Agent Advertisement. O valor deveria ser aleatório e ter pelo menos 32 bits. O nó móvel copiava esse valor para a MN-FA Challenge extension do pedido de registro.

A procedência importava mais que a aparência aleatória. O gateway visitado sabia quais valores acabara de oferecer. Assim podia testar frescor sem antecipar a conclusão de identidade. Era uma certeza local e limitada, não um certificado universal.

O texto impediu que o desafio circulasse sozinho. Depois da MN-FA Challenge precisava existir Mobile-Foreign Authentication ou MN-AAA Authentication. Uma requisição com desafio, mas sem uma dessas extensões, devia ser descartada silenciosamente.

Quando havia associação direta, Mobile-Foreign Authentication vinculava os campos ao segredo compartilhado. Sem essa relação, o nó tinha de usar MN-AAA e deveria acrescentar o Network Access Identifier da RFC 2794. O realm ajudava a encaminhar a verificação ao domínio certo; o nome declarado não autenticava a si mesmo.

O pacote carregava etapas diferentes. Challenge dizia “este é o valor recente que estou respondendo”. Authenticator dizia “estes dados foram ligados a este segredo e algoritmo”. A infraestrutura AAA verificava. A política decidia se a inscrição era permitida. Não havia atalho legítimo entre essas frases.

Três códigos preservavam a causa. MISSING_CHALLENGE marcava ausência. STALE_CHALLENGE marcava valor já utilizado pelo mesmo nó. UNKNOWN_CHALLENGE dizia que o valor não era o último devolvido com sucesso nem estava nos anúncios recentes de CHALLENGE_WINDOW. O registro da IANA ainda conserva essas atribuições.

Chamar todos de “falha de autenticação” eliminaria a informação mais valiosa. Estrutura incompleta, reutilização e emissão não reconhecida pelo agente exigem diagnósticos distintos. A RFC tornou observável a fronteira de estado, não apenas o resultado final.

Havia uma exceção precisa para retransmissão. Se Identification e Challenge eram iguais e o agente ainda mantinha o registro correspondente como pending, o mesmo pedido podia ser encaminhado outra vez. Fora desse estado vivo, repetir o desafio normalmente produzia STALE_CHALLENGE.

A proteção contra replay, portanto, dependia de memória. Era preciso lembrar emissor, nó, desafio, Identification, pedido pendente e expiração. Rejeitar qualquer duplicata quebraria a recuperação de perdas; aceitar qualquer valor “recente” apagaria a diferença que se tentava defender.

O resultado do Home Agent também precisava voltar amarrado. Se o desafio seguia no pedido encaminhado, o agente estrangeiro o guardava no estado pending e rejeitava uma Registration Reply sem o mesmo valor. A correspondência provava qual resposta pertencia àquela transação, não que uma rota funcionava nem que um aplicativo recebeu bytes.

Quando uma associação MN-FA direta permitia verificar e remover o material local, o agente deveria reter o Identification em seus registros. O campo podia sair da mensagem seguinte; a obrigação de manter a fronteira antirreplay continuava.

A “verification infrastructure” ficou propositalmente fora de Mobile IPv4. O agente estrangeiro podia entregar material de autenticação a ela e esperar uma notificação segura. A RFC não determinou o protocolo interno nem o produto. Definiu a junção entre sistemas, não um controlador único.

Essa camada comum pequena permitia adaptação. Redes podiam manter bases de credenciais e regras diferentes, desde que o significado do desafio, do authenticator e do resultado não fosse perdido entre elas. A interoperabilidade estava na costura.

Para caber em sistemas existentes, CHAP_SPI 2 descreveu um cálculo MD5 no estilo CHAP, compatível com práticas de RADIUS. A própria RFC avisou que esse método era mais fraco que HMAC-MD5 e deveria ser evitado sempre que possível. A compatibilidade que abre a porta não deve ser confundida com segurança permanente.

O mecanismo ainda tinha uma borda de negação de serviço. Um pedido repetido podia provocar uma resposta de rejeição enquanto uma aceitação legítima continuava a caminho. O móvel poderia interpretar a primeira resposta como resultado definitivo. Frescor local não ordenava todos os eventos distribuídos.

Desafios menores que quatro bytes exigiam guardar também Identification para reforçar a unicidade. Estado e entropia se complementavam. A palavra “aleatório” não preenchia os bits ausentes.

Em 2007, a RFC 4721 substituiu a RFC 3012. Passou a exigir registro dos valores aplicáveis por nó e proibiu usar um valor anunciado antes do último que já servira para registro. Também esclareceu anúncios e respostas, acrescentou proteção contra mensagens falsas e introduziu HMAC-MD5.

As mudanças não provam um incidente específico. Elas mostram que o significado de “novo” depende de uma história ordenada: quem emitiu, para qual nó, qual valor já foi aceito, qual pedido permanece pendente e qual autenticação cobre o conjunto.

A tese não repete a RFC 2002. O Mobile IPv4 básico estabelecia binding temporário entre home address e care-of address. A RFC 3012 cuidava do momento anterior no limite visitado, antes de o Home Agent aceitar estado.

Também não é simplesmente PPP CHAP. No PPP, peer e authenticator participavam da autenticação de um enlace. Aqui, o agente estrangeiro fornecia frescor a uma inscrição Mobile IPv4 e podia depender de uma infraestrutura AAA separada. Reutilizar uma forma de digest não reutilizava a mesma autoridade.

A lente de especificação inicial mínima de Lu Heng ajuda a ver a força do desenho: tornar comuns somente formato, ordem, janela, erros e correlação. Verificador e política continuavam locais e substituíveis. Running-Code Primacy impede concluir implantação apenas porque a regra foi publicada.

Uma captura prova que o valor voltou. O log criptográfico prova a verificação. O registro de política prova a autorização. O Home Agent prova o binding. A observação de tráfego prova o uso. Dizer “challenge-response” não permite fundir esses recibos.

O gateway lançou o desafio porque esse era o fato que podia produzir sozinho. A confiança ainda precisava chegar por outros sistemas. A honestidade histórica da RFC 3012 está nessa separação.

Sources