Dva identiteta u jednoj IKEv2 prijavi: prvo mašina, zatim korisnik

Klijentski certifikat se validira, prva razmjena završava, a zatim se veza zaustavlja s greškom o dodatnom krugu autentifikacije. Ništa u lancu certifikata nije pogrešno i ništa se u mreži nije promijenilo. Gateway je konfigurisan da zahtijeva drugi dokaz od strane koja se povezuje, a klijent ga nikada ne šalje. Odlučiti ko šta dokazuje i kojim redom jeste cijeli zadatak, i počinje čitanjem politike sa endpointa na kojem stojite. Dva dokaza različite vrste, u fiksnom redu, jeste projektna odluka, a ne polje za označavanje.

Simptom: neuspjeh nakon uspješnog prvog dokaza

Prva razmjena završava i log izgleda zdravo, sve dok gateway ne zatraži korisnički identitet kroz EAP. Tada se rukovanje zaustavlja ili vraća grešku protokola koja imenuje dodatni krug. Potpuno važeći certifikat mašine biva odbijen iz razloga koji nema nikakve veze s njegovom valjanošću. Politika je tražila drugi dokaz, a odgovor klijenta nikada nije stigao.

Oba opisa tog neuspjeha su tačna zavisno od toga gdje stojite. Sa klijentove strane to izgleda kao server koji odbija važeći certifikat, a sa serverske strane kao klijent koji ne može dovršiti prijavu. Isti događaj se čita kao problem povjerenja u jednom logu i problem sposobnosti u drugom. Samo konfigurisana politika vam kaže koji je.

Šta ekstenzija dodaje, a šta ne

IKEv2 nosi ekstenziju za više od jedne razmjene autentifikacije unutar jedne sesije. RFC 4739 opisuje, između ostalih sljedova, klijenta koji dokazuje identitet certifikatom i zatim autentificira osobu kroz EAP. Dokument je Experimental, što znači da vam nijedna implementacija ne duguje tu funkciju. Ne pretpostavljajte ništa o podršci dok je partner ne dogovori.

Obje strane moraju podržavati ekstenziju i dogovoriti je tokom razmjene. Gateway konfigurisan za drugi krug ne može prisiliti klijenta da ga izvede, a klijent koji ga podržava neće ga koristiti ako server ne zatraži. Ta asimetrija je razlog zašto se neuspjeh obično pojavljuje kao istek vremena ili greška protokola, a ne kao jasna izjava o sposobnosti. Čitanje konfiguracije jedne strane kaže vam pola onoga što će se dogoditi.

Jedan dokaz po endpointu je uobičajen oblik i to nije ovaj dizajn. Gateway predstavlja svoj certifikat, korisnik odgovara kroz EAP, i svaka strana je autentificirala drugu tačno jednom. Ta dva dokaza dolaze sa suprotnih endpointa, pa nijedan ne govori ništa odvojeno o mašini i osobi koja je koristi.

EAP-TLS je treći oblik i ni on nije ovaj. Tamo se klijentski certifikat predstavlja unutar EAP metode, pa klijent ipak dovršava jednu IKE autentifikaciju. Vjerodajnice mogu izgledati identično slučaju s više krugova, dok protokol nosi jedan krug umjesto dva. Zato dizajn kopiran iz EAP-TLS instalacije pada upravo tamo gdje se očekuje drugi dokaz.

Ista datoteka se na gatewayu čita drugačije

Ista swanctl datoteka čita se drugačije zavisno od toga gdje se izvršava, i to je dio koji zbunjuje ljude. Na laptopu je gateway partner, a na gatewayu je partner laptop, pa pišite local stranu kao ko sam ja, a remote stranu kao koga ću prihvatiti. local blok opisuje kako se ovaj endpoint autentificira, a remote blok navodi šta zahtijeva od drugog kraja. Kopiranje bloka između dvije datoteke preokreće njegovo značenje bez promjene ijednog znaka. Upoređivanje dvije datoteke ne kaže gotovo ništa, jer iste riječi u svakoj znače suprotno.

Pozicija sekcije određuje njen red, osim ako je broj kruga ne nadjača. Zato dodatne local ili remote sekcije opisuju dodatne krugove, a ne alternative, a eksplicitni broj kruga u referenci za swanctl.conf postoji upravo da to redanje učini namjernim. Bez njega premještanje bloka mijenja ponašanje. Zato i dvije konfiguracije koje na papiru izgledaju ekvivalentne mogu raditi u suprotnom redu.

To pravilo redanja proizvodi način neuspjeha koji vrijedi zapamtiti. Drugi remote blok nije još jedna prihvatljiva opcija; to je drugi zahtjev, zato se politika koja se čita kao ili/ili ponaša kao i-zatim. Gateway politika može prihvatiti certifikat upisane mašine i zatim zahtijevati EAP razmjenu tog korisnika, tim redom.

Razlikujte krugove od nezavisnih faktora

Dva kruga nisu automatski dva nezavisna faktora. Ponavljanje dokaza ili držanje dvije vjerodajnice u istom spremištu ne daje snagu koju je dizajn trebao dodati. Nezavisnost je svojstvo toga kako se tajne čuvaju i šta ih kompromitira, a ne koliko razmjena protokol izvodi. Dizajn koji broji krugove kao faktore precjenjuje ono što ima. Ta razlika je najvažnija kada pitanje usklađenosti pita koliko faktora prijava stvarno koristi.

Certifikat mašine dokazuje posjedovanje svog prihvaćenog ključa i ništa više. To nije hardverska atestacija ni izvještaj o zdravlju uređaja, pa politika koja treba informacije o stanju treba drugi mehanizam. Polje subject također nije inventarna oznaka kojoj možete vjerovati, jer subject bira onaj ko je certifikat izdao ili upisao. Ako dizajn treba dokaz da je mašina zdrava, taj dokaz mora doći od komponente koja mjeri mašinu.

Zapišite šta svaki krug stvarno dokazuje prije nego ga dodate. Kada dva kruga isto dokažu dvaput, drugi dodaje latenciju i tikete podrške umjesto sigurnosti. Ta bilješka je i ono što zaustavlja raspravu o tome zaslužuje li dodatni krug svoju cijenu.

Napišite pravilo uparivanja i testirajte odbijanja

Odlučite koje mašinske identitete smiju upariti s kojim ljudima, i napišite pravilo tamo gdje živi provođenje. Dvije važeće vjerodajnice jedna uz drugu ne dokazuju ništa o uparivanju, jer je uparivanje odluka o autorizaciji, a ne rezultat autentifikacije. Evidencija upisa ili pozadinski sistem autentifikacije mora provoditi odnos koji organizacija želi.

Zatim testirajte šta treba da padne: prihvaćen korisnik na neodobrenoj mašini, neodobren korisnik koji ima vjerodajnicu mašine i partner koji ne može izvesti dodatni krug. Ako sva tri tiho dobiju isti pristup, politika opisuje namjeru umjesto da je provodi. Uporedite deklarisanu konfiguraciju s onim što daemon prijavljuje, jer veza koja se nikada nije poklopila izgleda isto kao pravilo koje je prošlo:

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

Provjerite dogovorene krugove i autorizaciju koja iz toga slijedi, ne samo uspješnu prijavu. I ne posežite za starim IKEv1 XAuth postavkama kao prečicom: uskladite protokol, role, red i stvarno ponašanje klijenta umjesto da brišete potreban krug dok veza ne uspije. Brisanje kruga koji pada jeste način na koji dizajn s dva dokaza tiho postaje dizajn s jednim dokazom koji niko nije pregledao. Zadržite brisanje u zapisu promjena.