Tempos de vida das SA no IKEv2: renovação de chaves suave, expiração rígida, reautenticação separada

Os temporizadores decidem quando as chaves de um túnel são substituídas, e os dois limiares envolvidos costumam ser lidos como um só. Não são. Um tempo de vida suave pede ao par que construa uma substituição enquanto a associação de segurança atual ainda transporta tráfego, e um tempo de vida rígido é o prazo após o qual a associação antiga desaparece, quer a substituição tenha funcionado ou não. Entre eles há uma janela de sobreposição que existe para que os pacotes não caiam num vão.

O que um tempo de vida realmente limita

Uma associação de segurança IPsec é um conjunto de estado criptográfico: chaves para uma direção, um índice de parâmetros de segurança, um conjunto de algoritmos e um seletor. O tempo de vida limita quanto tempo esse estado pode ser usado, o que limita quanto tráfego uma chave protege. É uma medida de contenção para a chave, não uma afirmação sobre quanto deve durar uma sessão de usuário.

As associações de controle IKE têm chaves próprias e tempos de vida próprios, separadas das associações filhas que transportam dados. É o primeiro ponto em que as pessoas confundem dois calendários.

O suave inicia a substituição, o rígido encerra o estado antigo

Quando o limiar suave se aproxima, o par inicia uma substituição. As implementações costumam disparar cedo e aleatorizam o momento para que um concentrador com centenas de túneis não renove as chaves de todos de uma vez. No IKEv2 a substituição é uma troca CREATE_CHILD_SA com nonces novos, mais uma troca Diffie-Hellman quando a confidencialidade persistente está configurada. O resultado é um novo par de associações com chaves novas.

A sobreposição importa. Por um breve período o par pode manter as associações antiga e nova, e uma captura pode mostrar dois conjuntos de identificadores. Isso é o mecanismo funcionando, não uma falha.

O limiar rígido não perdoa. Se a substituição não estiver concluída até lá, a associação antiga deve ser retirada e o tráfego protegido apenas por ela para. Renovações de chaves falhadas repetidas que chegam até a expiração rígida são o sinal operacional para investigar, porque o túnel é sustentado por um prazo em cada ciclo.

Os limites de uso podem disparar antes de qualquer relógio

O tempo não é a única fronteira. As implementações podem limitar os bytes ou pacotes protegidos por uma chave, e um túnel ocupado atingirá um limite de uso muito antes de um temporizador de várias horas. O strongSwan expõe ajustes separados de tempo de vida e margem para tempo, bytes e pacotes, o que significa que o ponto efetivo de renovação é o limiar que chegar primeiro, menos a margem configurada.

Quando um túnel se renova muito mais vezes do que as horas configuradas sugerem, verifique os limites de bytes e pacotes antes de culpar o relógio. Um link saturado e um link inativo com os mesmos ajustes de tempo terão taxas de renovação de chaves visivelmente diferentes, e apenas um deles segue o temporizador.

Cada par aplica a sua própria política

O IKEv2 não negocia um único tempo de vida que ambos os pares devam exibir de forma idêntica. Cada lado aplica a sua política local e pode iniciar a substituição quando o seu próprio limite se aproxima, como descrito na RFC 7296 secção 2.8. Assim, uma divergência entre as horas configuradas de dois pares não é automaticamente um defeito, embora valores muito diferentes possam causar agitação se um lado continuar a substituir estado que o outro acabou de instalar.

Coordenar significa um comportamento compatível: janelas de sobreposição suficientemente longas para a troca, margens que deixam espaço para novas tentativas e monitorização que mostra que lado iniciou cada renovação.

Renovar chaves não é reautenticar

Uma renovação de chaves atualiza as chaves sob a relação autenticada existente. Uma reautenticação repete a verificação de identidade, quer seja uma troca de certificados ou uma conversa EAP. As duas funcionam em calendários separados e uma renovação bem-sucedida não diz nada sobre se a conta ainda deve ter acesso.

Essa distinção importa para a revogação. Desativar uma conta, revogar um certificado ou terminar uma sessão são decisões de acesso que exigem política explícita na implementação; não decorrem do temporizador da SA, e uma renovação de chaves pode continuar tranquilamente para uma identidade que já foi privada de direitos.

O que registar por túnel

Registe qual associação provocou a renovação, os identificadores antigo e novo, qual limiar disparou e se a substituição foi concluída dentro da sobreposição. Esses quatro campos tornam um problema de renovação visível antes de se tornar uma paragem, e distinguem uma política agressiva de uma que está a falhar.

Mantenha o calendário de remoção de acesso ao lado desse registo, e não dentro dele. A higiene criptográfica e a política de identidade são controlos diferentes, e um túnel que roda chaves a tempo pode ainda estar a manter uma sessão que ninguém pretendia conservar.