To identitetar i éi IKEv2-innlogging: først maskina, deretter brukaren

Eit klientsertifikat blir validert, den første utvekslinga blir fullført, og så stoppar sambandet med ein feil om ein ekstra autentiseringsrunde. Ingenting i sertifikatkjeda er gale, og ingenting i nettverket er endra. Gatewayen er konfigurert til å krevje eit andre prov frå den tilkopla sida, og klienten sender aldri eitt. Å avgjere kven som provar kva, og i kva rekkjefølgje, er heile oppgåva, og ho byrjar med å lese policyen frå endepunktet du står på. To prov av ulik type, i fast rekkjefølgje, er ei designavgjerd og ikkje ein avkrysningsboks.

Symtomet: feil etter eit vellukka første prov

Den første utvekslinga blir fullført og loggen ser sunn ut, heilt til gatewayen ber om ein brukaridentitet via EAP. Då stoppar handtrykket eller returnerer ein protokollfeil som namngjev den ekstra runda. Eit fullstendig gyldig maskinsertifikat blir avvist av ein grunn som ikkje har noko med gyldet å gjere. Policyen bad om eit andre prov, og svaret frå klienten kom aldri.

Begge skildringane av den feilen er riktige avhengig av kvar du står. Frå klientsida ser det ut som ein tenar som avviser eit gyldig sertifikat, og frå tenarsida som ein klient som ikkje klarer å fullføre innlogginga. Den same hendinga blir lesen som eit tillitsproblem i éi logg og eit kapasitetsproblem i den andre. Berre den konfigurerte policyen fortel deg kva det er.

Kva utvidinga legg til, og kva ho ikkje gjer

IKEv2 ber ei utviding for å køyre meir enn éin autentiseringsutveksling i éi enkelt økt. RFC 4739 skisserer, blant andre sekvensar, ein klient som provar ein sertifikatidentitet og deretter autentiserer ein person via EAP. Dokumentet er Experimental, noko som betyr at ingen implementasjon skuldar deg funksjonen. Ikkje gå ut frå noko om støtte før motparten forhandlar om han.

Begge sider må støtte utvidinga og bli samde om ho under utvekslinga. Ein gateway konfigurert for ein andre runde kan ikkje tvinge ein klient til å gjere ein, og ein klient som støttar det brukar det ikkje med mindre tenaren ber om det. Den asymmetrien er grunnen til at feilen vanlegvis viser seg som eit tidsavbrot eller protokollfeil i staden for ei klar fråsegn om kapasitet. Å lese konfigurasjonen til éi side fortel deg halvparten av det som vil skje.

Eitt prov per endepunkt er den normale forma, og dette er ikkje det designet. Gatewayen presenterer sertifikatet sitt, brukaren svarar via EAP, og kvar side har autentisert den andre nøyaktig éin gong. Dei to prova kjem frå motsette endepunkt, så ingen av dei seier noko eige om maskina og personen som brukar ho.

EAP-TLS er ei tredje form, og det er heller ikkje denne. Der blir eit klientsertifikat presentert inne i ein EAP-metode, så klienten fullfører framleis éin enkelt IKE-autentisering. Legitimasjonen kan sjå identisk ut med tilfellet med fleire rundar, medan protokollen ber éi runde i staden for to. Difor feilar eit design kopiert frå ein EAP-TLS-installasjon nettopp på punktet der det andre provet blir venta.

Den same fila blir lesen annleis på gatewayen

Den same swanctl-fila blir lesen annleis avhengig av kvar ho køyrer, 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-sida som kven eg er og remote-sida som kven eg vil godta. Ein local-blokk skildrar korleis dette endepunktet autentiserer seg sjølv, og ein remote-blokk angir kva han krev av den andre enden. Å kopiere ein blokk mellom dei to filene snur tydinga utan å endre eitt einaste teikn. Å samanlikne dei to filene fortel deg nesten ingenting, fordi dei same orda betyr det motsette i kvar av dei.

Plasseringa til ein seksjon avgjer rekkjefølgja, med mindre eit rundenummer overstyrer ho. Difor skildrar ekstra local- eller remote-seksjonar ekstra rundar og ikkje alternativ, og det eksplisitte rundenummeret i swanctl.conf-referansen finst nettopp for å gjere den rekkjefølgja medviten. Utan det endrar flytting av ein blokk åtferda. Difor kan to konfigurasjonar som ser like ut på papiret oppføre seg i motsett rekkjefølgje.

Den ordensregelen produserer feilmodusen som er verdt å hugse. Ein andre remote-blokk er ikkje nok eit akseptabelt alternativ; han er eit andre krav, og difor oppfører ein policy som blir lesen som anten/eller seg som og-deretter. Ein gateway-policy kan godta sertifikatet til den registrerte maskina og deretter krevje EAP-utvekslinga til den brukaren, i den rekkjefølgja.

Skil rundar frå uavhengige faktorar

To rundar er ikkje automatisk to uavhengige faktorar. Å gjenta eit prov, eller å ha to legitimasjonar i same lager, gir ikkje styrken designet skulle leggje til. Uavhengigheit er ein eigenskap ved korleis løyndommane blir haldne og kva som kompromitterer dei, ikkje ved kor mange utvekslingar protokollen køyrer. Eit design som tel rundar som faktorar overdriv kva det har. Den skilnaden betyr mest når eit samsvarsspørsmål spør kor mange faktorar innlogginga faktisk brukar.

Eit maskinsertifikat provar at ein har sin godtekne nøkkel, og ikkje noko meir. Det er ikkje ein maskinvareattestasjon og ikkje ein einingshelserapport, så ein policy som treng tilstandsinformasjon treng ein annan mekanisme. Subject-feltet er heller ikkje ein inventaretikett du kan stole på, fordi subject blir valt av den som gav ut eller registrerte sertifikatet. Viss designet treng prov for at maskina er sunn, må det provet kome frå ein komponent som måler maskina.

Skriv ned kva kvar runde faktisk provar før du legg han til. Når to rundar provar det same to gonger, legg den andre til ventetid og støttebillettar i staden for tryggleik. Den noten er også det som stoppar ein diskusjon om korvidt den ekstra runda er kostnaden verd.

Skriv paringsregelen og test avvisingane

Avgjer kva maskinidentitetar som kan bli para med kva personar, og skriv regelen der handhevinga bur. To gyldige legitimasjonar side ved side provar ingenting om paringa, fordi paringa er ei autorisasjonsavgjerd og ikkje eit autentiseringsresultat. Registreringsoppføringane eller autentiseringsbackenden må handheve forholdet organisasjonen ønskjer.

Test deretter kva som skal feile: ein godteken brukar på ei ikkje-godkjend maskin, ein ikkje-godkjend brukar som har legitimasjonen til maskina, og ein motpart som ikkje kan utføre den ekstra runda. Viss alle tre stille får same tilgang, skildrar policyen ein intensjon i staden for å handheve han. Samanlikn den erklærte konfigurasjonen med det daemonen rapporterer, fordi eit samband som aldri samsvarte ser identisk ut med ein regel som gjekk gjennom:

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

Kontroller dei forhandla rundane og autorisasjonen som følgjer, ikkje berre den vellukka innlogginga. Og grip ikkje etter gamle IKEv1 XAuth-innstillingar som ein snarvveg: tilpass protokollen, rollane, rekkjefølgja og den faktiske åtferda til klienten i staden for å slette ein påkravd runde til eit samband lukkast. Å slette runda som feilar er måten eit design med to prov stille blir eit design med eitt prov som ingen har gått gjennom. Hald slettinga i endringsloggen.