To identiteter i ét IKEv2-login: først maskinen, derefter brugeren

Et klientcertifikat valideres, den første udveksling fuldføres, og så stopper forbindelsen med en fejl om en ekstra autentificeringsrunde. Intet i certifikatkæden er galt, og intet i netværket er ændret. Gatewayen er konfigureret til at kræve et andet bevis fra den tilsluttende side, og klienten sender aldrig et. At afgøre, hvem der beviser hvad, og i hvilken rækkefølge, er hele opgaven, og den begynder med at læse politikken fra det endpoint, du står på. To beviser af forskellig art i en fast rækkefølge er en designbeslutning og ikke et afkrydsningsfelt.

Symptomet: fejl efter et vellykket første bevis

Den første udveksling fuldføres, og loggen ser sund ud, indtil gatewayen beder om en brugeridentitet via EAP. Så går håndtrykket i stå eller returnerer en protokolfejl, der navngiver den ekstra runde. Et fuldstændig gyldigt maskincertifikat afvises af en grund, der intet har med dets gyldighed at gøre. Politikken bad om et andet bevis, og klientens svar kom aldrig.

Begge beskrivelser af den fejl er korrekte afhængigt af, hvor du står. Fra klientens side ser det ud som en server, der afviser et gyldigt certifikat, og fra serverens side ser det ud som en klient, der ikke kan fuldføre login. Den samme hændelse læses som et tillidsproblem i den ene log og et kapabilitetsproblem i den anden. Kun den konfigurerede politik fortæller dig hvilken.

Hvad udvidelsen tilføjer, og hvad den ikke tilføjer

IKEv2 bærer en udvidelse til at køre mere end én autentificeringsudveksling i en enkelt session. RFC 4739 skitserer blandt andre forløb en klient, der beviser en certifikatidentitet og derefter autentificerer en person via EAP. Dokumentet er Experimental, hvilket betyder, at ingen implementering skylder dig funktionen. Antag intet om understøttelse, før modparten forhandler den.

Begge sider skal understøtte udvidelsen og blive enige om den under udvekslingen. En gateway, der er konfigureret til en anden runde, kan ikke tvinge en klient til at udføre en, og en klient, der understøtter det, bruger det ikke, medmindre serveren beder om det. Den asymmetri er grunden til, at fejlen normalt viser sig som en timeout eller en protokolfejl i stedet for en klar erklæring om kapabilitet. At læse den ene sides konfiguration fortæller dig halvdelen af, hvad der vil ske.

Et bevis pr. endpoint er den normale form, og det er ikke dette design. Gatewayen fremviser sit certifikat, brugeren svarer via EAP, og hver side har autentificeret den anden præcis én gang. De to beviser kommer fra modsatte endpoints, så ingen af dem siger noget særskilt om maskinen og personen, der bruger den.

EAP-TLS er en tredje form, og det er heller ikke denne. Der fremvises et klientcertifikat inde i en EAP-metode, så klienten fuldfører stadig én enkelt IKE-autentificering. Legitimationsoplysningerne kan se identiske ud med tilfældet med flere runder, mens protokollen bærer én runde i stedet for to. Derfor fejler et design kopieret fra en EAP-TLS-installation netop på det punkt, hvor det andet bevis forventes.

Den samme fil læses anderledes på gatewayen

Den samme swanctl-fil læses anderledes afhængigt af, hvor den kører, og det er den del, der får folk til at snuble. På laptopens side er gatewayen modparten, og på gatewayen er laptopens side modparten, så skriv local-siden som hvem jeg er og remote-siden som hvem jeg vil acceptere. En local-blok beskriver, hvordan dette endpoint autentificerer sig selv, og en remote-blok angiver, hvad den kræver af den anden ende. At kopiere en blok mellem de to filer vender dens betydning uden at ændre et eneste tegn. At sammenligne de to filer fortæller dig næsten intet, fordi de samme ord betyder det modsatte i hver af dem.

En sektions placering fastlægger dens rækkefølge, medmindre et rundenummer tilsidesætter den. Derfor beskriver ekstra local- eller remote-sektioner ekstra runder og ikke alternativer, og det eksplicitte rundenummer i swanctl.conf-referencen findes netop for at gøre den rækkefølge bevidst. Uden det ændrer flytningen af en blok adfærden. Derfor kan to konfigurationer, der ser ens ud på papiret, også opføre sig i modsat rækkefølge.

Den ordensregel frembringer den fejltilstand, der er værd at huske. En anden remote-blok er ikke endnu en acceptabel mulighed; den er et andet krav, og derfor opfører en politik, der læses som enten/eller, sig som og-derefter. En gatewaypolitik kan acceptere den registrerede maskines certifikat og derefter kræve den brugers EAP-udveksling, i den rækkefølge.

Skeln mellem runder og uafhængige faktorer

To runder er ikke automatisk to uafhængige faktorer. At gentage et bevis eller have to legitimationsoplysninger i samme lager giver ikke den styrke, designet skulle tilføje. Uafhængighed er en egenskab ved, hvordan hemmelighederne opbevares, og hvad der kompromitterer dem, ikke ved hvor mange udvekslinger protokollen kører. Et design, der tæller runder som faktorer, overdriver, hvad det har. Den sondring er vigtigst, når et compliance-spørgsmål spørger, hvor mange faktorer login faktisk bruger.

Et maskincertifikat beviser besiddelse af sin accepterede nøgle og intet mere. Det er ikke en hardwareattestering og ikke en enhedssundhedsrapport, så en politik, der har brug for tilstandsoplysninger, har brug for en anden mekanisme. Subject-feltet er heller ikke et inventarmærke, du kan stole på, fordi subject vælges af den, der har udstedt eller registreret certifikatet. Hvis designet har brug for bevis for, at maskinen er sund, skal det bevis komme fra en komponent, der måler maskinen.

Skriv ned, hvad hver runde faktisk beviser, før du tilføjer den. Når to runder beviser det samme to gange, tilføjer den anden latenstid og supportbilletter i stedet for sikkerhed. Den note er også det, der stopper en diskussion om, hvorvidt den ekstra runde er sin pris værd.

Skriv parringsreglen, og test afvisningerne

Beslut, hvilke maskinidentiteter der må parres med hvilke personer, og skriv reglen der, hvor håndhævelsen bor. To gyldige legitimationsoplysninger side om side beviser intet om parringen, fordi parringen er en autorisationsbeslutning og ikke et autentificeringsresultat. Registreringsoplysningerne eller autentificeringsbackenden skal håndhæve det forhold, organisationen ønsker.

Test derefter, hvad der bør fejle: en accepteret bruger på en ikke-godkendt maskine, en ikke-godkendt bruger med maskinens legitimationsoplysning og en modpart, der ikke kan udføre den ekstra runde. Hvis alle tre stille får den samme adgang, beskriver politikken en hensigt i stedet for at håndhæve den. Sammenlign den erklærede konfiguration med det, daemonen rapporterer, fordi en forbindelse, der aldrig matchede, ser identisk ud med en regel, der gik igennem:

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

Kontrollér de forhandlede runder og den resulterende autorisation, ikke kun det vellykkede login. Og grib ikke efter gamle IKEv1 XAuth-indstillinger som en genvej: afstem protokollen, rollerne, rækkefølgen og klientens faktiske adfærd i stedet for at slette en påkrævet runde, indtil en forbindelse lykkes. At slette den runde, der fejler, er måden, hvorpå et design med to beviser stille bliver et design med ét bevis, som ingen har gennemgået. Behold sletningen i ændringsloggen.