Dúas identidades nun inicio de sesión IKEv2: primeiro a máquina, despois o usuario

Un certificado de cliente valídase, o primeiro intercambio complétase e entón a conexión detense cun erro sobre unha rolda adicional de autenticación. Nada na cadea de certificados está mal e nada na rede cambiou. A pasarela está configurada para esixir unha segunda proba ao lado que se conecta, e o cliente nunca a envía. Decidir quen demostra que, e en que orde, é toda a tarefa, e comeza lendo a política desde o extremo no que está. Dúas probas de distinto tipo, nunha orde fixa, son unha decisión de deseño e non unha casa de verificación.

O síntoma: fallo tras unha primeira proba correcta

O primeiro intercambio complétase e o rexistro parece san, ata que a pasarela pide unha identidade de usuario mediante EAP. Entón o saldo detense ou devolve un erro de protocolo que nomea a rolda adicional. Un certificado de máquina perfectamente válido rexéitase por un motivo que non ten nada que ver coa súa validez. A política pedía unha segunda proba, e a resposta do cliente nunca chegou.

As dúas descricións dese fallo son exactas segundo onde estea. Desde o lado do cliente parece un servidor que rexeita un certificado válido, e desde o lado do servidor parece un cliente que non pode rematar o inicio de sesión. O mesmo suceso lese como un problema de confianza nun rexistro e un problema de capacidade no outro. Só a política configurada lle di cal é.

Que engade a extensión e que non

IKEv2 leva unha extensión para executar máis dun intercambio de autenticación dentro dunha soa sesión. RFC 4739 esboza, entre outras secuencias, un cliente que demostra unha identidade de certificado e despois autentica unha persoa mediante EAP. O documento é Experimental, o que significa que ningunha implementación lle debe a función. Non supoña nada sobre o soporte ata que o par o negocie.

Ambos os lados teñen que soportar a extensión e acordala durante o intercambio. Unha pasarela configurada para unha segunda rolda non pode obrigar un cliente a facer unha, e un cliente que a soporta non a usará se o servidor non o pide. Esa asimetría é a razón pola que o fallo adoita aparecer como un tempo de espera ou un erro de protocolo en lugar dunha declaración clara sobre a capacidade. Ler a configuración dun lado dille a metade do que ocorrerá.

Unha proba por extremo é a forma normal, e este non é ese deseño. A pasarela presenta o seu certificado, o usuario responde por EAP, e cada lado autenticou o outro exactamente unha vez. Esas dúas probas veñen de extremos opostos, así que ningunha di nada por separado sobre a máquina e a persoa que a usa.

EAP-TLS é unha terceira forma, e tampouco é esta. Alí un certificado de cliente preséntase dentro dun método EAP, así que o cliente segue completando unha única autenticación IKE. As credenciais poden parecer idénticas ao caso de varias roldas mentres o protocolo leva unha rolda en lugar de dúas. Por iso un deseño copiado dun despregamento EAP-TLS falla xusto onde se espera a segunda proba.

O mesmo ficheiro lese distinto na pasarela

O mesmo ficheiro swanctl lese distinto segundo onde se execute, e esa é a parte que fai tropezar a xente. No portátil a pasarela é o par, e na pasarela o portátil é o par, así que escriba o lado local como quen son eu e o lado remote como a quen aceptarei. Un bloque local describe como se autentica este extremo, e un bloque remote indica que esixe do outro extremo. Copiar un bloque entre os dous ficheiros inverte o seu significado sen cambiar un só carácter. Comparar os dous ficheiros non lle di case nada, porque as mesmas palabras significan cousas opostas en cada un.

A posición dunha sección fixa a súa orde salvo que un número de rolda a substitúa. Por iso as seccións local ou remote adicionais describen roldas adicionais e non alternativas, e o número de rolda explícito en a referencia de swanctl.conf existe precisamente para facer deliberado esa orde. Sen el, mover un bloque cambia o comportamento. Por iso tamén dúas configuracións que sobre o papel parecen equivalentes poden comportarse en ordes opostas.

Esa regra de orde produce o modo de fallo que paga a pena recordar. Un segundo bloque remote non é outra opción aceptable; é unha segunda esixencia, e por iso unha política que se le como ou/ou compórtase como e-despois. Unha política de pasarela pode aceptar o certificado da máquina inscrita e despois esixir o intercambio EAP dese usuario, nesa orde.

Distinga roldas de factores independentes

Dúas roldas non son automaticamente dous factores independentes. Repetir unha proba, ou ter dúas credenciais no mesmo almacén, non achega a forza que o deseño debía engadir. A independencia é unha propiedade de como se gardan os segredos e de que os compromete, non de cantos intercambios executa o protocolo. Un deseño que conta roldas como factores exaxera o que ten. Esa distinción importa sobre todo cando unha pregunta de cumprimento pregunta cantos factores usa realmente o inicio de sesión.

Un certificado de máquina demostra a posesión da súa clave aceptada, e nada máis. Non é unha atestación de hardware nin un informe de saúde do dispositivo, así que unha política que necesita información de postura necesita outro mecanismo. O campo subject tampouco é unha etiqueta de inventario fiable, porque o subject escólleo quen emitiu ou inscribiu o certificado. Se o deseño necesita unha proba de que a máquina está sa, esa proba ten que vir dun compoñente que mide a máquina.

Anote que demostra realmente cada rolda antes de engadila. Cando dúas roldas demostran o mesmo dúas veces, a segunda engade latencia e tickets de soporte en lugar de garantía. Esa nota é tamén o que detén unha discusión sobre se a rolda adicional merece o seu custo.

Escriba a regra de emparellamento e probe as denegacións

Decida que identidades de máquina poden emparellarse con que persoas, e escriba a regra onde vive a aplicación. Dúas credenciais válidas unha ao lado da outra non demostran nada sobre o emparellamento, porque o emparellamento é unha decisión de autorización e non un resultado de autenticación. Os rexistros de inscrición ou o backend de autenticación teñen que aplicar a relación que a organización quere.

Despois probe que debería fallar: un usuario aceptado nunha máquina non aprobada, un usuario non aprobado coa credencial da máquina e un par que non pode realizar a rolda adicional. Se os tres reciben en silencio o mesmo acceso, a política describe unha intención en lugar de aplicala. Compare a configuración declarada co que informa o daemon, porque unha conexión que nunca coincidiu parece idéntica a unha regra que pasou:

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

Comprobe as roldas negociadas e a autorización resultante, non só o inicio de sesión correcto. E non recorra a axustes antigos de IKEv1 XAuth como atallo: faga coincidir o protocolo, os roles, a orde e o comportamento real do cliente en lugar de borrar unha rolda necesaria ata que unha conexión funcione. Borrar a rolda que falla é como un deseño de dúas probas se converte en silencio nun deseño dunha proba que ninguén revisou. Deixe o borrado no rexistro de cambios.