Duas identidades num início de sessão IKEv2: primeiro a máquina, depois o utilizador

Um certificado de cliente é validado, a primeira troca é concluída e, em seguida, a ligação para com um erro sobre uma ronda adicional de autenticação. Nada na cadeia de certificados está errado e nada na rede mudou. O gateway está configurado para exigir uma segunda prova ao lado que se liga, e o cliente nunca a envia. Decidir quem prova o quê, e por que ordem, é a tarefa toda, e começa por ler a política a partir do extremo onde está. Duas provas de tipos diferentes, numa ordem fixa, são uma decisão de projeto e não uma caixa de verificação.

O sintoma: falha depois de uma primeira prova bem-sucedida

A primeira troca é concluída e o registo parece são, até o gateway pedir uma identidade de utilizador através de EAP. Aí o handshake para ou devolve um erro de protocolo que nomeia a ronda adicional. Um certificado de máquina perfeitamente válido é rejeitado por um motivo que nada tem a ver com a sua validade. A política pedia uma segunda prova, e a resposta do cliente nunca chegou.

Ambas as descrições dessa falha são exatas conforme o lugar onde está. Do lado do cliente parece um servidor que rejeita um certificado válido, e do lado do servidor parece um cliente que não consegue terminar o início de sessão. O mesmo acontecimento lê-se como um problema de confiança num registo e um problema de capacidade no outro. Só a política configurada lhe diz qual é.

O que a extensão acrescenta e o que não acrescenta

O IKEv2 transporta uma extensão para executar mais do que uma troca de autenticação numa única sessão. O RFC 4739 esboça, entre outras sequências, um cliente que prova uma identidade de certificado e depois autentica uma pessoa através de EAP. O documento é Experimental, o que significa que nenhuma implementação lhe deve a funcionalidade. Não assuma nada sobre suporte até o par o negociar.

Ambos os lados têm de suportar a extensão e concordar com ela durante a troca. Um gateway configurado para uma segunda ronda não pode obrigar um cliente a fazer uma, e um cliente que a suporta não a usará se o servidor não o pedir. É essa assimetria que faz com que a falha surja habitualmente como um tempo limite ou um erro de protocolo em vez de uma declaração clara sobre a capacidade. Ler a configuração de um lado diz-lhe metade do que vai acontecer.

Uma prova por extremo é a forma normal, e este não é esse desenho. O gateway apresenta o seu certificado, o utilizador responde por EAP, e cada lado autenticou o outro exatamente uma vez. Essas duas provas vêm de extremos opostos, portanto nenhuma diz nada de separado sobre a máquina e a pessoa que a utiliza.

O EAP-TLS é uma terceira forma, e também não é esta. Aí um certificado de cliente é apresentado dentro de um método EAP, portanto o cliente continua a concluir uma única autenticação IKE. As credenciais podem parecer idênticas ao caso de várias rondas, enquanto o protocolo transporta uma ronda em vez de duas. É por isso que um desenho copiado de uma instalação EAP-TLS falha exatamente no ponto onde se espera a segunda prova.

O mesmo ficheiro lê-se de forma diferente no gateway

O mesmo ficheiro swanctl lê-se de forma diferente conforme o local onde é executado, e é essa a parte que faz tropeçar as pessoas. No portátil o gateway é o par, e no gateway o portátil é o par, por isso escreva o lado local como quem sou eu e o lado remote como quem vou aceitar. Um bloco local descreve como este extremo se autentica, e um bloco remote indica o que exige do outro extremo. Copiar um bloco entre os dois ficheiros inverte o seu significado sem alterar um único carácter. Comparar os dois ficheiros não lhe diz quase nada, porque as mesmas palavras significam coisas opostas em cada um.

A posição de uma secção determina a sua ordem, a menos que um número de ronda a substitua. Por isso as secções local ou remote adicionais descrevem rondas adicionais e não alternativas, e o número de ronda explícito em a referência do swanctl.conf existe precisamente para tornar essa ordem deliberada. Sem ele, mover um bloco altera o comportamento. É também por isso que duas configurações que parecem equivalentes no papel podem comportar-se em ordens opostas.

Essa regra de ordem produz o modo de falha que vale a pena recordar. Um segundo bloco remote não é outra opção aceitável; é uma segunda exigência, e é por isso que uma política que se lê como ou/ou se comporta como e-depois. Uma política de gateway pode aceitar o certificado da máquina inscrita e depois exigir a troca EAP desse utilizador, nessa ordem.

Distinga rondas de fatores independentes

Duas rondas não são automaticamente dois fatores independentes. Repetir uma prova, ou guardar duas credenciais no mesmo armazém, não dá a força que o desenho devia acrescentar. A independência é uma propriedade da forma como os segredos são guardados e do que os compromete, não de quantas trocas o protocolo executa. Um desenho que conta rondas como fatores sobrestima o que tem. Essa distinção importa sobretudo quando uma pergunta de conformidade pergunta quantos fatores o início de sessão usa realmente.

Um certificado de máquina prova a posse da sua chave aceite, e nada mais. Não é uma atestação de hardware nem um relatório de saúde do dispositivo, por isso uma política que precisa de informação de postura precisa de outro mecanismo. O campo subject também não é uma etiqueta de inventário fiável, porque o subject é escolhido por quem emitiu ou inscreveu o certificado. Se o desenho precisa de prova de que a máquina está sã, essa prova tem de vir de um componente que mede a máquina.

Anote o que cada ronda prova realmente antes de a acrescentar. Quando duas rondas provam duas vezes a mesma coisa, a segunda acrescenta latência e pedidos de suporte em vez de garantia. Essa nota é também o que trava uma discussão sobre se a ronda adicional vale o seu custo.

Escreva a regra de emparelhamento e teste as recusas

Decida que identidades de máquina podem emparelhar com que pessoas, e escreva a regra onde vive a aplicação. Duas credenciais válidas lado a lado não provam nada sobre o emparelhamento, porque o emparelhamento é uma decisão de autorização e não um resultado de autenticação. Os registos de inscrição ou o backend de autenticação têm de aplicar a relação que a organização quer.

Depois teste o que devia falhar: um utilizador aceite numa máquina não aprovada, um utilizador não aprovado que detém a credencial da máquina e um par que não consegue executar a ronda adicional. Se os três receberem em silêncio o mesmo acesso, a política descreve uma intenção em vez de a aplicar. Compare a configuração declarada com o que o daemon relata, porque uma ligação que nunca correspondeu parece idêntica a uma regra que passou:

swanctl --list-conns
swanctl --list-sas

Verifique as rondas negociadas e a autorização resultante, não apenas o início de sessão bem-sucedido. E não recorra a definições antigas de IKEv1 XAuth como atalho: faça corresponder o protocolo, as funções, a ordem e o comportamento real do cliente em vez de apagar uma ronda necessária até uma ligação funcionar. Apagar a ronda que falha é a forma como um desenho de duas provas se torna discretamente num desenho de uma prova que ninguém reviu. Mantenha a eliminação no registo de alterações.