Twee identiteiten in één IKEv2-aanmelding: eerst de machine, dan de gebruiker

Een clientcertificaat wordt gevalideerd, de eerste uitwisseling slaagt, en dan stopt de verbinding met een fout over een extra authenticatieronde. Niets in de certificaatketen is verkeerd en niets in het netwerk is veranderd. De gateway is geconfigureerd om een tweede bewijs van de verbindende kant te eisen, en de client stuurt er nooit een. Beslissen wie wat bewijst, en in welke volgorde, is de hele taak, en die begint met het lezen van het beleid vanaf het eindpunt waarop je staat. Twee bewijzen van verschillende aard, in een vaste volgorde, zijn een ontwerpbeslissing en geen selectievakje.

Het symptoom: een fout na een geslaagd eerste bewijs

De eerste uitwisseling slaagt en het log ziet er gezond uit, totdat de gateway een gebruikersidentiteit via EAP vraagt. Dan blijft de handshake hangen of komt er een protocolfout terug die de extra ronde noemt. Een volkomen geldig machinecertificaat wordt afgewezen om een reden die niets met de geldigheid te maken heeft. Het beleid vroeg om een tweede bewijs, en het antwoord van de client kwam nooit.

Beide beschrijvingen van die fout zijn juist, afhankelijk van waar je staat. Vanaf de clientkant lijkt het een server die een geldig certificaat weigert, en vanaf de serverkant een client die de aanmelding niet kan afmaken. Dezelfde gebeurtenis leest als een vertrouwensprobleem in het ene log en een capaciteitsprobleem in het andere. Alleen het geconfigureerde beleid zegt je welke het is.

Wat de uitbreiding toevoegt, en wat niet

IKEv2 draagt een uitbreiding om meer dan één authenticatie-uitwisseling binnen één sessie uit te voeren. RFC 4739 schetst, naast andere reeksen, een client die een certificaatidentiteit bewijst en daarna een persoon via EAP authenticeert. Het document is Experimental, wat betekent dat geen enkele implementatie je deze functie verschuldigd is. Neem niets aan over ondersteuning voordat de tegenpartij erover onderhandelt.

Beide kanten moeten de uitbreiding ondersteunen en er tijdens de uitwisseling overeenstemming over bereiken. Een gateway die voor een tweede ronde is geconfigureerd kan een client er niet toe dwingen, en een client die haar ondersteunt gebruikt haar niet als de server er niet om vraagt. Die asymmetrie is de reden dat de fout zich meestal als een time-out of protocolfout aandient in plaats van als een duidelijke verklaring over de mogelijkheid. De configuratie van één kant lezen vertelt je de helft van wat er gaat gebeuren.

Eén bewijs per eindpunt is de normale vorm, en dit is niet dat ontwerp. De gateway presenteert haar certificaat, de gebruiker antwoordt via EAP, en elke kant heeft de andere precies één keer geauthenticeerd. Die twee bewijzen komen van tegenovergestelde eindpunten, dus geen van beide zegt iets aparts over de machine en de persoon die haar gebruikt.

EAP-TLS is een derde vorm, en dat is deze ook niet. Daar wordt een clientcertificaat binnen een EAP-methode gepresenteerd, dus de client voltooit nog steeds één IKE-authenticatie. De inloggegevens kunnen identiek lijken aan het geval met meerdere rondes, terwijl het protocol één ronde draagt in plaats van twee. Daarom faalt een ontwerp dat van een EAP-TLS-implementatie is gekopieerd precies op het punt waar het tweede bewijs wordt verwacht.

Hetzelfde bestand leest anders op de gateway

Hetzelfde swanctl-bestand leest anders afhankelijk van waar het draait, en dat is het deel waar mensen over struikelen. Op de laptop is de gateway de tegenpartij, en op de gateway is de laptop dat, dus schrijf de local-kant als wie ik ben en de remote-kant als wie ik zal accepteren. Een local-blok beschrijft hoe dit eindpunt zichzelf authenticeert, en een remote-blok vermeldt wat het van de andere kant eist. Een blok tussen de twee bestanden kopiëren keert de betekenis om zonder één teken te wijzigen. De twee bestanden vergelijken vertelt je bijna niets, omdat dezelfde woorden in elk ervan het tegenovergestelde betekenen.

De positie van een sectie bepaalt de volgorde, tenzij een rondenummer die overstemt. Extra local- of remote-secties beschrijven daarom extra rondes en geen alternatieven, en het expliciete rondenummer in de swanctl.conf-referentie bestaat juist om die volgorde bewust te maken. Zonder dat verandert het verplaatsen van een blok het gedrag. Daarom kunnen twee configuraties die op papier gelijkwaardig lijken zich in tegengestelde volgorde gedragen.

Die ordeningsregel levert de foutmodus op die het onthouden waard is. Een tweede remote-blok is geen andere aanvaardbare optie; het is een tweede eis, en daarom gedraagt een beleid dat als of/of leest zich als en-dan. Een gatewaybeleid kan het certificaat van de ingeschreven machine accepteren en daarna de EAP-uitwisseling van die gebruiker eisen, in die volgorde.

Onderscheid rondes van onafhankelijke factoren

Twee rondes zijn niet automatisch twee onafhankelijke factoren. Een bewijs herhalen, of twee inloggegevens in dezelfde opslag houden, levert niet de sterkte op die het ontwerp zou toevoegen. Onafhankelijkheid is een eigenschap van hoe de geheimen worden bewaard en wat ze compromitteert, niet van hoeveel uitwisselingen het protocol uitvoert. Een ontwerp dat rondes als factoren telt, overschat wat het heeft. Dat onderscheid is het belangrijkst wanneer een compliancevraag vraagt hoeveel factoren de aanmelding werkelijk gebruikt.

Een machinecertificaat bewijst het bezit van zijn geaccepteerde sleutel, en niets meer. Het is geen hardware-attestation en geen gezondheidsrapport van het apparaat, dus een beleid dat positie-informatie nodig heeft, heeft een ander mechanisme nodig. Het subject-veld is ook geen betrouwbaar inventarislabel, omdat het subject wordt gekozen door wie het certificaat heeft uitgegeven of ingeschreven. Als het ontwerp een bewijs nodig heeft dat de machine gezond is, moet dat bewijs van een component komen die de machine meet.

Schrijf op wat elke ronde werkelijk bewijst voordat je haar toevoegt. Wanneer twee rondes hetzelfde twee keer bewijzen, voegt de tweede latentie en supporttickets toe in plaats van zekerheid. Die notitie is ook wat een discussie stopt over de vraag of de extra ronde haar kosten waard is.

Schrijf de koppelingsregel en test de weigeringen

Beslis welke machine-identiteiten met welke personen mogen worden gekoppeld, en schrijf de regel waar de handhaving leeft. Twee geldige inloggegevens naast elkaar bewijzen niets over de koppeling, omdat de koppeling een autorisatiebeslissing is en geen authenticatieresultaat. De inschrijvingsgegevens of de authenticatiebackend moeten de relatie afdwingen die de organisatie wil.

Test daarna wat zou moeten mislukken: een geaccepteerde gebruiker op een niet-goedgekeurde machine, een niet-goedgekeurde gebruiker met de inloggegevens van de machine, en een tegenpartij die de extra ronde niet kan uitvoeren. Als alle drie stil dezelfde toegang krijgen, beschrijft het beleid een bedoeling in plaats van die af te dwingen. Vergelijk de verklaarde configuratie met wat de daemon meldt, want een verbinding die nooit overeenkwam ziet er identiek uit als een regel die slaagde:

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

Controleer de onderhandelde rondes en de resulterende autorisatie, niet alleen de geslaagde aanmelding. En grijp niet naar oude IKEv1 XAuth-instellingen als een kortere weg: laat het protocol, de rollen, de volgorde en het werkelijke gedrag van de client kloppen in plaats van een vereiste ronde te verwijderen tot een verbinding slaagt. De ronde verwijderen die faalt is hoe een ontwerp met twee bewijzen stil een ontwerp met één bewijs wordt dat niemand heeft beoordeeld. Houd de verwijdering in het wijzigingsregister.