To identiteter i én IKEv2-innlogging: først maskinen, deretter brukeren

Et klientsertifikat valideres, den første utvekslingen fullføres, og så stopper forbindelsen med en feil om en ekstra autentiseringsrunde. Ingenting i sertifikatkjeden er galt, og ingenting i nettverket er endret. Gatewayen er konfigurert til å kreve et andre bevis fra den tilkoblede siden, og klienten sender aldri ett. Å avgjøre hvem som beviser hva, og i hvilken rekkefølge, er hele oppgaven, og den begynner med å lese policyen fra endepunktet du står på. To bevis av ulik type, i fast rekkefølge, er en designbeslutning og ikke en avkrysningsboks.

Symptomet: feil etter et vellykket første bevis

Den første utvekslingen fullføres og loggen ser sunn ut, helt til gatewayen ber om en brukeridentitet via EAP. Da stopper håndtrykket eller returnerer en protokollfeil som navngir den ekstra runden. Et fullstendig gyldig maskinsertifikat blir avvist av en grunn som ikke har noe med gyldigheten å gjøre. Policyen ba om et andre bevis, og klientens svar kom aldri.

Begge beskrivelsene av den feilen er riktige avhengig av hvor du står. Fra klientsiden ser det ut som en server som avviser et gyldig sertifikat, og fra serversiden som en klient som ikke klarer å fullføre innloggingen. Den samme hendelsen leses som et tillitsproblem i én logg og et kapabilitetsproblem i den andre. Bare den konfigurerte policyen forteller deg hvilken det er.

Hva utvidelsen legger til, og hva den ikke gjør

IKEv2 bærer en utvidelse for å kjøre mer enn én autentiseringsutveksling i én enkelt økt. RFC 4739 skisserer, blant andre sekvenser, en klient som beviser en sertifikatidentitet og deretter autentiserer en person via EAP. Dokumentet er Experimental, noe som betyr at ingen implementasjon skylder deg funksjonen. Ikke anta noe om støtte før motparten forhandler om den.

Begge sider må støtte utvidelsen og bli enige om den under utvekslingen. En gateway konfigurert for en andre runde kan ikke tvinge en klient til å gjøre en, og en klient som støtter det bruker det ikke med mindre serveren ber om det. Den asymmetrien er grunnen til at feilen vanligvis vises som en tidsavbrudd eller protokollfeil i stedet for en klar erklæring om kapabilitet. Å lese konfigurasjonen til én side forteller deg halvparten av det som vil skje.

Ett bevis per endepunkt er den normale formen, og dette er ikke det designet. Gatewayen presenterer sertifikatet sitt, brukeren svarer via EAP, og hver side har autentisert den andre nøyaktig én gang. De to bevisene kommer fra motsatte endepunkter, så ingen av dem sier noe eget om maskinen og personen som bruker den.

EAP-TLS er en tredje form, og det er heller ikke denne. Der presenteres et klientsertifikat inne i en EAP-metode, så klienten fullfører fortsatt én enkelt IKE-autentisering. Legitimasjonen kan se identisk ut med tilfellet med flere runder, mens protokollen bærer én runde i stedet for to. Derfor feiler et design kopiert fra en EAP-TLS-installasjon nettopp på punktet der det andre beviset forventes.

Den samme filen leses annerledes på gatewayen

Den samme swanctl-filen leses annerledes avhengig av hvor den kjører, og det er den delen som får folk til å snuble. På laptopen er gatewayen motparten, og på gatewayen er laptopen det, så skriv local-siden som hvem jeg er og remote-siden som hvem jeg vil godta. En local-blokk beskriver hvordan dette endepunktet autentiserer seg selv, og en remote-blokk angir hva den krever av den andre enden. Å kopiere en blokk mellom de to filene snur betydningen uten å endre et eneste tegn. Å sammenligne de to filene forteller deg nesten ingenting, fordi de samme ordene betyr det motsatte i hver av dem.

Plasseringen til en seksjon bestemmer rekkefølgen, med mindre et rundenummer overstyrer den. Derfor beskriver ekstra local- eller remote-seksjoner ekstra runder og ikke alternativer, og det eksplisitte rundenummeret i swanctl.conf-referansen finnes nettopp for å gjøre den rekkefølgen bevisst. Uten det endrer flytting av en blokk atferden. Derfor kan to konfigurasjoner som ser like ut på papiret oppføre seg i motsatt rekkefølge.

Den ordensregelen produserer feilmodusen som er verdt å huske. En andre remote-blokk er ikke nok et akseptabelt alternativ; den er et andre krav, og derfor oppfører en policy som leses som enten/eller seg som og-deretter. En gateway-policy kan godta sertifikatet til den registrerte maskinen og deretter kreve EAP-utvekslingen til den brukeren, i den rekkefølgen.

Skill runder fra uavhengige faktorer

To runder er ikke automatisk to uavhengige faktorer. Å gjenta et bevis, eller å ha to legitimasjoner i samme lager, gir ikke styrken designet skulle legge til. Uavhengighet er en egenskap ved hvordan hemmelighetene holdes og hva som kompromitterer dem, ikke ved hvor mange utvekslinger protokollen kjører. Et design som teller runder som faktorer overdriver hva det har. Den forskjellen betyr mest når et samsvarsspørsmål spør hvor mange faktorer innloggingen faktisk bruker.

Et maskinsertifikat beviser besittelse av sin godtatte nøkkel, og ikke noe mer. Det er ikke en maskinvareattestering og ikke en enhetshelserapport, så en policy som trenger tilstandsinformasjon trenger en annen mekanisme. Subject-feltet er heller ikke en inventaretikett du kan stole på, fordi subject velges av den som utstedte eller registrerte sertifikatet. Hvis designet trenger bevis for at maskinen er sunn, må det beviset komme fra en komponent som måler maskinen.

Skriv ned hva hver runde faktisk beviser før du legger den til. Når to runder beviser det samme to ganger, legger den andre til ventetid og støttebilletter i stedet for trygghet. Den noten er også det som stopper en diskusjon om hvorvidt den ekstra runden er kostnaden verd.

Skriv paringsregelen og test avvisningene

Bestem hvilke maskinidentiteter som kan pares med hvilke personer, og skriv regelen der håndhevelsen bor. To gyldige legitimasjoner side ved side beviser ingenting om paringen, fordi paringen er en autorisasjonsbeslutning og ikke et autentiseringsresultat. Registreringsoppføringene eller autentiseringsbackenden må håndheve forholdet organisasjonen ønsker.

Test deretter hva som skal feile: en godtatt bruker på en ikke-godkjent maskin, en ikke-godkjent bruker som har maskinens legitimasjon, og en motpart som ikke kan utføre den ekstra runden. Hvis alle tre stille får samme tilgang, beskriver policyen en intensjon i stedet for å håndheve den. Sammenlign den erklærte konfigurasjonen med det daemonen rapporterer, fordi en forbindelse som aldri samsvarte ser identisk ut med en regel som gikk gjennom:

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

Kontroller de forhandlede rundene og autorisasjonen som følger, ikke bare den vellykkede innloggingen. Og grip ikke etter gamle IKEv1 XAuth-innstillinger som en snarvei: tilpass protokollen, rollene, rekkefølgen og klientens faktiske atferd i stedet for å slette en påkrevd runde til en forbindelse lykkes. Å slette runden som feiler er måten et design med to bevis stille blir et design med ett bevis som ingen har gjennomgått. Behold slettingen i endringsloggen.