Resumo

  • RFC 5387 chamou de continuidade de associação a garantia fraca do BTNS: o mesmo par não autenticado permanece ligado à comunicação durante a vida de uma SA, sem ganhar uma identidade estável entre SAs.
  • RFC 5386 exigiu que entradas BTNS viessem depois das relações autenticadas; um par que correspondesse a uma entrada forte e falhasse nela tinha de ser rejeitado, nunca reclassificado como anônimo.
  • Latching, channel binding, restrição de seletores e BTNS_OK fechavam limites diferentes; nenhum deles podia ser inferido apenas de uma SA instalada.

Uma SA tem começo e fim próprios

Uma Security Association IPsec é estado direcional com chaves, algoritmos, contadores, vida útil e parâmetros de proteção. Enquanto existe, ESP ou AH pode oferecer integridade, antirreplay e, conforme o caso, confidencialidade. BTNS não torna esses mecanismos fictícios.

O que ele remove é a obrigação de provar, na camada de rede, uma identidade externa do par. A assinatura IKEv2 é verificada com a chave pública que o próprio par incluiu. O resultado demonstra controle da chave privada naquele intercâmbio. Não demonstra que uma autoridade associou a chave a uma empresa, nome DNS, endereço ou pessoa.

RFC 5387 descreve o resultado como continuidade de associação. O interlocutor de uma SA permanece o interlocutor daquela SA. A frase é deliberadamente temporal. Não significa “proprietário da chave X” fora da sessão nem “mesmo equipamento” depois que outra SA nasce.

Essa garantia pode proteger uma transferência longa contra ataques fora do caminho após o estabelecimento. Ainda assim, um atacante ativo pode interceptar o primeiro intercâmbio. Better than nothing é uma descrição de limite, não um certificado de identidade.

O rekey abriu uma nova pergunta

SAs expiram por tempo ou volume e precisam ser substituídas. RFC 5387 observa que a troca cria uma janela na qual um atacante no caminho pode tentar ocupar a associação seguinte. No BTNS, sobretudo no modo Stand-Alone, ele não precisa reproduzir a identidade autenticada da vítima, pois essa identidade não existia no IKE inicial.

Duas SAs podem ser individualmente bem formadas e ainda pertencer a pares diferentes. O contador da primeira não autentica a segunda. Um log de “rekey concluído” também não prova que a aplicação continuou no mesmo canal.

Connection latching vincula um fluxo de camada superior a uma sequência de SAs semelhantes. O cache desse latch entre sessões pode reduzir spoofing intersessão. Channel binding incorpora características do canal na autenticação da camada superior, permitindo que os extremos detectem quando um intermediário concatenou duas associações.

O recibo correto preserva a ascendência do rekey, as duas chaves públicas, o identificador do latch, o valor de channel binding e o resultado da autenticação superior. Se uma chave muda, o sistema deve saber qual política autorizou a transição. “Ambas as SAs eram válidas” não fecha a continuidade entre elas.

A política forte possuía o primeiro veto

Antes de qualquer questão de rekey, RFC 5386 precisava impedir um downgrade na admissão inicial. A Peer Authorization Database é ordenada. O sistema procura primeiro uma entrada não-BTNS para a identidade afirmada pelo par.

Se encontrar uma relação conhecida, essa entrada define como o par deve se autenticar. Uma falha é terminal. O nó deve rejeitar a proposta; não pode continuar até uma entrada BTNS genérica.

Somente quando nenhuma entrada comum corresponde é permitido converter localmente a identidade em PUBLICKEY, usando a chave apresentada, e procurar as entradas BTNS. Todas elas seguem logicamente as entradas fortes. Só pode existir um wildcard, e ele deve ser o último.

O contraste é “desconhecido” contra “conhecido, porém reprovado”. O primeiro pode receber um serviço anônimo deliberado. O segundo já recebeu um veredito da relação que tinha autoridade para avaliá-lo. Um wildcard que apaga esse veredito deixa de ser exceção e vira mecanismo de rebaixamento.

O par admitido ainda não possuía qualquer fluxo

Depois da IKE SA, a Child SA negocia identidades de tráfego. RFC 5386 não permite que as restrições do wildcard se sobreponham às entradas normais da PAD. O texto propõe outra busca durante a negociação para conferir os seletores afirmados.

Assim, uma chave anônima aceita para um serviço não pode se apropriar do endereço de um host conhecido ou da rede de um gateway autenticado. A admissão do par e a autorização para representar tráfego são decisões distintas.

RFC 7619 descreve risco semelhante para NULL Authentication: um par atrás de NAT poderia pedir o seletor de um servidor DNS e desviar o tráfego que o outro lado destinava a esse servidor. Isolamento, endereço atribuído e limites de seletor continuam necessários mesmo quando a criptografia da SA funciona.

A Security Policy Database fornece outro limite. Tráfego de par BTNS só casa com entrada marcada BTNS_OK. Suporte no produto não habilita automaticamente todo o host. A autorização pertence a uma classe de tráfego local.

Channel-Bound BTNS detectava tarde

Stand-Alone BTNS protege a associação sem autenticação superior. Channel-Bound BTNS adiciona uma autenticação na aplicação ou protocolo superior e a vincula ao canal IPsec.

Esse arranjo pode chegar a proteção comparável contra MITM quando a autenticação e o binding são fortes. Mas a ordem dos acontecimentos é diferente da IKE autenticada. A IKE BTNS pode ter sucesso, criar SAs e consumir recursos antes de a camada superior detectar o intermediário.

RFC 5387 alerta para mecanismos superiores que enviam senhas ou derivados úteis a ataques offline. Detectar a fraude depois não recolhe o segredo exposto. Também recomenda limites de recursos, porque o par anônimo que completa IKE é um cliente protocolar válido, ainda que não seja confiável.

Portanto, higher_auth_failed não é um erro tardio sem consequência. É um evento ligado à SA já criada, ao material possivelmente enviado e à remoção posterior do estado. Uma autenticação superior bem-sucedida também não deve reescrever o registro inicial como se IKE tivesse certificado aquela identidade.

Leap of faith não vinha embutido

RFC 5386 não especificou leap of faith nem fallback para IP em claro. RFC 5387 comparou o possível cache de credenciais BTNS ao SSH e mostrou diferenças importantes. SSH prevê aviso, escolha do usuário e reutilização de uma chave associada a um nome. BTNS aceitaria uma credencial nova sempre que a política anônima a permitisse.

Mesmo um cache BTNS reautenticaria, no máximo, uma fonte de rede. NAT pode juntar várias fontes; multihoming pode separar uma; mobilidade e mudança de titularidade podem deslocar endereços. A persistência da chave só ganha significado se uma autoridade declarar a que identidade, escopo e época ela pertence.

RFC 7670 posteriormente generalizou chaves públicas brutas em IKEv2 e exige validação fora de banda quando se quer confiança na autenticidade. RFC 7619 tornou a ausência de identidade explícita com ID_NULL. Nenhum texto converte o primeiro encontro em verdade histórica sem política adicional.

O modo fraco não era uma escada para o claro

RFC 5386 declara que não define um modo oportunista que caia para IP desprotegido quando o outro lado não suporta IKEv2. RFC 5387 aconselha usar BTNS no lugar de nenhuma segurança, não no lugar de segurança mais forte.

Uma implementação que tenta certificado, aceita falha, tenta chave anônima e depois transmite em claro criou três rebaixamentos. O resultado final pode ser disponibilidade, mas não a política do RFC.

O registro deve guardar as decisões negativas. Uma identidade conhecida rejeitada é evidência de que o primeiro veto funcionou. Um seletor recusado mostra que a admissão anônima não tomou o espaço do parceiro. Uma regra SPD sem BTNS_OK recusando o tráfego mostra que a exceção ficou local.

Limite das fontes

Os RFCs comprovam regras e modelos de ameaça. Não comprovam implementação atual, implantação, prevalência ou ataque real. O mecanismo de chave RSA de RFC 4306 mudou com RFC 7296 e RFC 7670. Qualquer afirmação sobre produção requer versão, configuração, trilha de IKE, política carregada e observação de pacotes.

Na disciplina de Lu Heng, a continuidade de uma relação não deve usurpar a identidade. Chave, PAD, SPD, SA, latch, principal superior e efeito aplicativo são camadas relacionadas. O controle se mantém quando cada uma emite seu próprio recibo e nenhuma associação passada é usada para fabricar autoridade futura.