Två identiteter i en IKEv2-inloggning: maskin, sedan användare

Ett klientcertifikat verifieras, det första utbytet slutförs och sedan stannar anslutningen med ett fel om ytterligare en autentiseringsomgång. Inget i certifikatkedjan är fel och inget i nätverket har förändrats. Gatewayen har konfigurerats att kräva ett andra bevis från den anslutande sidan, och klienten skickar aldrig ett. Att avgöra vem som bevisar vad, i vilken ordning, är hela uppgiften, och den börjar med att läsa policyn från den endpoint du står på. Två bevis av olika slag, i en fast ordning, är ett designbeslut och inte en kryssruta.

Symtomet: misslyckande efter ett lyckat första bevis

Det första utbytet slutförs och loggen ser frisk ut, tills gatewayen begär en användaridentitet via EAP. Handskakningen stannar då eller returnerar ett protokollfel som namnger den extra omgången. Ett fullt giltigt maskincertifikat avvisas av en anledning som inte har något med dess giltighet att göra. Policyn begärde ett andra bevis, och klientens svar kom aldrig fram.

Båda beskrivningarna av det misslyckandet är korrekta beroende på var du står. Från klientsidan ser det ut som en server som avvisar ett giltigt certifikat, och från serversidan ser det ut som en klient som inte kan slutföra inloggningen. Samma händelse läses som ett förtroendeproblem i en logg och ett kapacitetsproblem i den andra. Bara den konfigurerade policyn säger vilket det är.

Vad tillägget lägger till, och vad det inte gör

IKEv2 har ett tillägg för att köra mer än ett autentiseringsutbyte inom en enda session. RFC 4739 skisserar, bland andra sekvenser, en klient som bevisar en certifikatidentitet och sedan autentiserar en person via EAP. Dokumentet är experimentellt, vilket innebär att ingen implementation är skyldig dig funktionen. Anta inget om stöd förrän motparten förhandlar fram det.

Båda sidor måste stödja tillägget och komma överens om det under utbytet. En gateway som konfigurerats för en andra omgång kan inte tvinga en klient att utföra en, och en klient som stöder det använder det inte om inte servern ber om det. Den asymmetrin är varför felet oftast visar sig som en timeout eller ett protokollfel i stället för ett tydligt besked om kapacitet. Att läsa en sidas konfiguration berättar hälften av vad som kommer att hända.

Ett bevis per endpoint är den normala formen, och det är inte den här designen. Gatewayen visar sitt certifikat, användaren svarar på EAP, och varje sida har autentiserat den andra exakt en gång. De två bevisen kommer från motsatta endpoints, så inget av dem säger något separat om maskinen och personen som använder den.

EAP-TLS är en tredje form, och den är inte heller den här. Där visas ett klientcertifikat inuti en EAP-metod, så klienten slutför fortfarande en enda IKE-autentisering. Referenserna kan se identiska ut med fallet med flera omgångar, medan protokollet bär en omgång i stället för två. Det är därför en design kopierad från en EAP-TLS-driftsättning misslyckas precis där det andra beviset förväntas.

Samma fil läses annorlunda på gatewayen

Samma swanctl-fil läses annorlunda beroende på var den körs, och det är delen som förvirrar folk. På laptopen är gatewayen motparten, och på gatewayen är det laptopen, så skriv den lokala sidan som vem jag är och den remote sidan som vem jag kommer att acceptera. Ett local-block beskriver hur den här endpointen autentiserar sig själv, och ett remote-block anger vad den kräver av den andra änden. Att kopiera ett block mellan de två filerna inverterar dess betydelse utan att ändra ett enda tecken. Att diffa de två filerna säger nästan ingenting, eftersom samma ord betyder motsatta saker i varje.

En sektions position bestämmer dess ordning om inte ett omgångsnummer åsidosätter det. Ytterligare local- eller remote-sektioner beskriver därför ytterligare omgångar snarare än alternativ, och det uttryckliga omgångsnumret i swanctl.conf-referensen finns just för att göra den ordningen avsiktlig. Utan det ändrar ett flyttat block beteendet. Det är också därför två konfigurationer som ser likvärdiga ut på papper kan bete sig i motsatt ordning.

Den ordningsregeln ger det felsätt som är värt att komma ihåg. Ett andra remote-block är inte ännu ett acceptabelt alternativ; det är ett andra krav, vilket är varför en policy som läses som antingen/eller beter sig som och-sedan. En gatewaypolicy kan acceptera den registrerade maskinens certifikat och sedan kräva den användarens EAP-utbyte, i den ordningen.

Skilj omgångar från oberoende faktorer

Två omgångar är inte automatiskt två oberoende faktorer. Att upprepa ett bevis, eller att hålla två referenser i samma lager, ger inte den styrka som designen skulle lägga till. Oberoende är en egenskap hos hur hemligheterna hålls och vad som komprometterar dem, inte hos hur många utbyten protokollet kör. En design som räknar omgångar som faktorer överdriver vad den har. Den skillnaden spelar störst roll när en compliance-fråga frågar hur många faktorer inloggningen faktiskt använder.

Ett maskincertifikat bevisar innehav av dess accepterade nyckel, och inget mer. Det är inte en hårdvaruattestering och inte en rapport om enhetens hälsa, så en policy som behöver posture-information behöver en annan mekanism. Inte heller subject-fältet är en inventarieetikett du kan lita på, eftersom subject väljs av den som utfärdade eller registrerade certifikatet. Om designen behöver bevis på att maskinen är frisk måste det beviset komma från en komponent som mäter maskinen.

Skriv ner vad varje omgång faktiskt bevisar innan du lägger till den. När två omgångar bevisar samma sak två gånger lägger den andra till latens och supportärenden i stället för trygghet. Den anteckningen är också det som stoppar en diskussion om huruvida den extra omgången är värd sitt pris.

Skriv parningsregeln och testa avvisningarna

Bestäm vilka maskinidentiteter som får paras med vilka personer, och skriv regeln där verkställigheten finns. Två giltiga referenser sida vid sida bevisar ingenting om parningen, eftersom parningen är ett auktoriseringsbeslut och inte ett autentiseringsresultat. Registreringsposterna eller autentiseringsbackend måste verkställa den relation organisationen vill ha.

Testa sedan vad som ska misslyckas: en accepterad användare på en icke godkänd maskin, en icke godkänd användare som innehar maskinens referens, och en motpart som inte kan utföra den extra omgången. Om alla tre tyst får samma åtkomst beskriver policyn en avsikt i stället för att verkställa en. Jämför den deklarerade konfigurationen med vad daemonen rapporterar, eftersom en anslutning som aldrig matchade ser identisk ut med en regel som passerade:

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

Kontrollera de förhandlade omgångarna och den resulterande auktoriseringen, inte bara den lyckade inloggningen. Och ta inte till äldre XAuth-inställningar för IKEv1 som en genväg: matcha protokollet, rollerna, ordningen och klientens verkliga beteende i stället för att radera en obligatorisk omgång tills en anslutning lyckas. Att radera omgången som misslyckas är hur en design med två bevis tyst blir en design med ett bevis som ingen granskade. Behåll raderingen i ändringsloggen.