Dues identitats en un inici de sessió IKEv2: primer la màquina, després l'usuari

Un certificat de client es valida, el primer intercanvi es completa i llavors la connexió s'atura amb un error sobre una ronda addicional d'autenticació. No hi ha res malament a la cadena de certificats ni ha canviat res a la xarxa. La passarel·la s'ha configurat per exigir una segona prova al costat que es connecta, i el client no n'envia mai cap. Decidir qui demostra què, i en quin ordre, és tota la feina, i comença llegint la política des de l'extrem on sou. Dues proves de tipus diferents, en un ordre fix, són una decisió de disseny i no una casella de verificació.

El símptoma: fallada després d'una primera prova correcta

El primer intercanvi es completa i el registre sembla sa, fins que la passarel·la demana una identitat d'usuari mitjançant EAP. Llavors l'encaixada s'atura o retorna un error de protocol que anomena la ronda addicional. Un certificat de màquina perfectament vàlid es rebutja per un motiu que no té res a veure amb la seva validesa. La política demanava una segona prova, i la resposta del client no va arribar mai.

Totes dues descripcions d'aquesta fallada són exactes segons on sigueu. Des del costat del client sembla un servidor que rebutja un certificat vàlid, i des del costat del servidor sembla un client que no pot acabar l'inici de sessió. El mateix esdeveniment es llegeix com un problema de confiança en un registre i un problema de capacitat en l'altre. Només la política configurada us diu quin és.

Què afegeix l'extensió i què no

IKEv2 porta una extensió per executar més d'un intercanvi d'autenticació dins d'una sola sessió. RFC 4739 esbossa, entre altres seqüències, un client que demostra una identitat de certificat i després autentica una persona mitjançant EAP. El document és Experimental, cosa que vol dir que cap implementació us deu la funcionalitat. No suposeu res sobre el suport fins que l'altre extrem el negociï.

Tots dos costats han de suportar l'extensió i acordar-la durant l'intercanvi. Una passarel·la configurada per a una segona ronda no pot obligar un client a fer-ne una, i un client que la suporta no la farà servir si el servidor no ho demana. Aquesta asimetria és per què la fallada sol aparèixer com a temps d'espera o error de protocol en lloc d'una declaració clara sobre la capacitat. Llegir la configuració d'un costat explica la meitat del que passarà.

Una prova per extrem és la forma normal, i aquest no és aquest disseny. La passarel·la presenta el seu certificat, l'usuari respon per EAP, i cada costat ha autenticat l'altre exactament una vegada. Aquestes dues proves vénen d'extrems oposats, així que cap de les dues diu res per separat sobre la màquina i la persona que la fa servir.

EAP-TLS és una tercera forma, i tampoc no és aquesta. Allà un certificat de client es presenta dins d'un mètode EAP, així que el client encara completa una única autenticació IKE. Les credencials poden semblar idèntiques al cas de diverses rondes mentre el protocol porta una ronda en lloc de dues. Per això un disseny copiat d'una implantació EAP-TLS falla just on s'espera la segona prova.

El mateix fitxer es llegeix diferent a la passarel·la

El mateix fitxer swanctl es llegeix diferent segons on s'executa, i aquesta és la part que fa caure la gent. A l'ordinador portàtil la passarel·la és l'altre extrem, i a la passarel·la l'ordinador portàtil ho és, així que escriviu el costat local com qui sóc jo i el costat remote com qui acceptaré. Un bloc local descriu com aquest extrem s'autentica, i un bloc remote indica què exigeix de l'altre costat. Copiar un bloc entre els dos fitxers n'inverteix el significat sense canviar ni un caràcter. Comparar els dos fitxers no us diu gairebé res, perquè les mateixes paraules signifiquen coses oposades en cadascun.

La posició d'una secció fixa el seu ordre tret que un número de ronda la substitueixi. Per tant, les seccions local o remote addicionals descriuen rondes addicionals i no alternatives, i el número de ronda explícit a la referència de swanctl.conf existeix precisament per fer deliberat aquest ordre. Sense ell, moure un bloc canvia el comportament. Per això també dues configuracions que sobre el paper semblen equivalents poden comportar-se en ordres oposats.

Aquesta regla d'ordenació produeix el mode de fallada que val la pena recordar. Un segon bloc remote no és una altra opció acceptable; és una segona exigència, i per això una política que es llegeix com a o/u es comporta com a i-després. Una política de passarel·la pot acceptar el certificat de la màquina inscrita i després exigir l'intercanvi EAP d'aquest usuari, en aquest ordre.

Distingiu les rondes dels factors independents

Dues rondes no són automàticament dos factors independents. Repetir una prova, o tenir dues credencials al mateix magatzem, no proporciona la força que el disseny havia d'afegir. La independència és una propietat de com es guarden els secrets i de què els compromet, no de quantes rondes fa el protocol. Un disseny que compta rondes com a factors exagera el que té. Aquesta distinció importa sobretot quan una pregunta de compliment demana quants factors fa servir realment l'inici de sessió.

Un certificat de màquina demostra la possessió de la seva clau acceptada, i res més. No és una atestació de maquinari ni un informe de salut del dispositiu, així que una política que necessita informació de postura necessita un altre mecanisme. El camp subject tampoc no és una etiqueta d'inventari fiable, perquè el subject l'escull qui ha emès o inscrit el certificat. Si el disseny necessita una prova que la màquina és sana, aquesta prova ha de venir d'un component que mesura la màquina.

Anoteu què demostra realment cada ronda abans d'afegir-la. Quan dues rondes demostren el mateix dues vegades, la segona afegeix latència i tiquets de suport en lloc de garantia. Aquesta nota és també el que atura una discussió sobre si la ronda addicional val el seu cost.

Escriviu la regla d'aparellament i proveu les denegacions

Decidiu quines identitats de màquina es poden aparellar amb quines persones, i escriviu la regla on viu l'aplicació. Dues credencials vàlides una al costat de l'altra no demostren res sobre l'aparellament, perquè l'aparellament és una decisió d'autorització i no un resultat d'autenticació. Els registres d'inscripció o el backend d'autenticació han d'aplicar la relació que l'organització vol.

Després proveu què hauria de fallar: un usuari acceptat en una màquina no aprovada, un usuari no aprovat amb la credencial de la màquina i un extrem que no pot fer la ronda addicional. Si tots tres reben en silenci el mateix accés, la política descriu una intenció en lloc d'aplicar-ne una. Compareu la configuració declarada amb el que informa el dimoni, perquè una connexió que mai no ha coincidit sembla idèntica a una regla que ha passat:

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

Comproveu les rondes negociades i l'autorització resultant, no només l'inici de sessió correcte. I no recorreu a paràmetres antics d'IKEv1 XAuth com a drecera: feu coincidir el protocol, els rols, l'ordre i el comportament real del client en lloc d'esborrar una ronda necessària fins que una connexió funcioni. Esborrar la ronda que falla és com un disseny de dues proves es converteix en silenci en un disseny d'una prova que ningú no ha revisat. Deixeu l'esborrat al registre de canvis.