Dvě identity v jednom přihlášení IKEv2: nejprve počítač, potom uživatel

Klientský certifikát se ověří, první výměna doběhne a potom se spojení zastaví s chybou o dalším kole ověřování. V řetězu certifikátů není nic špatně a v síti se nic nezměnilo. Brána je nastavena tak, aby od připojující se strany vyžadovala druhý důkaz, a klient ho nikdy nepošle. Rozhodnout, kdo co dokazuje a v jakém pořadí, je celý úkol a začíná přečtením zásad z koncového bodu, na kterém stojíte. Dva důkazy různého druhu v pevném pořadí jsou návrhové rozhodnutí, ne zaškrtávací políčko.

Příznak: selhání po úspěšném prvním důkazu

První výměna doběhne a log vypadá zdravě, dokud brána nevyžádá identitu uživatele přes EAP. Pak se handshake zasekne nebo vrátí chybu protokolu, která pojmenuje další kolo. Zcela platný certifikát počítače je odmítnut z důvodu, který s jeho platností nemá nic společného. Zásady žádaly druhý důkaz a odpověď klienta nikdy nedorazila.

Oba popisy tohoto selhání jsou přesné podle toho, kde stojíte. Z pohledu klienta to vypadá jako server, který odmítá platný certifikát, a z pohledu serveru jako klient, který nedokáže dokončit přihlášení. Stejná událost se v jednom logu čte jako problém důvěry a v druhém jako problém schopností. Jen nastavené zásady vám řeknou, který z nich to je.

Co rozšíření přidává a co ne

IKEv2 nese rozšíření pro více než jednu výměnu ověřování v jedné relaci. RFC 4739 načrtává mimo jiné sled, kdy klient prokáže identitu certifikátem a poté ověří člověka přes EAP. Dokument má status Experimental, což znamená, že vám žádná implementace tuto funkci nedluží. Nepředpokládejte nic o podpoře, dokud ji protějšek nevyjedná.

Obě strany musí rozšíření podporovat a dohodnout se na něm během výměny. Brána nastavená na druhé kolo nemůže klienta donutit, aby ho provedl, a klient, který ho podporuje, ho nepoužije, pokud o to server nepožádá. Právě tato asymetrie je důvod, proč se selhání obvykle projeví jako časový limit nebo chyba protokolu místo jasného prohlášení o schopnostech. Přečtení konfigurace jedné strany vám řekne polovinu toho, co se stane.

Jeden důkaz na koncový bod je obvyklý tvar a toto není tento návrh. Brána předloží svůj certifikát, uživatel odpoví přes EAP a každá strana ověřila tu druhou přesně jednou. Tyto dva důkazy pocházejí z opačných koncových bodů, takže ani jeden neříká nic samostatného o počítači a člověku, který ho používá.

EAP-TLS je třetí tvar a také to není tento případ. Tam se klientský certifikát předkládá uvnitř metody EAP, takže klient stále dokončí jediné ověření IKE. Přihlašovací údaje mohou vypadat stejně jako v případě více kol, zatímco protokol nese jedno kolo místo dvou. Proto návrh zkopírovaný z nasazení EAP-TLS selhává přesně v bodě, kde se očekává druhý důkaz.

Stejný soubor se na bráně čte jinak

Stejný soubor swanctl se čte jinak podle toho, kde běží, a to je část, na které lidé klopýtnou. Na notebooku je protějškem brána a na bráně je protějškem notebook, takže stranu local pište jako kdo jsem a stranu remote jako koho přijmu. Blok local popisuje, jak se tento koncový bod ověřuje, a blok remote uvádí, co vyžaduje od druhého konce. Zkopírování bloku mezi oba soubory obrátí jeho význam, aniž by se změnil jediný znak. Porovnání obou souborů vám neřekne téměř nic, protože stejná slova v každém znamenají opak.

Pozice sekce určuje její pořadí, pokud ji nepřebije číslo kola. Dodatečné sekce local nebo remote tedy popisují další kola, nikoli alternativy, a výslovné číslo kola v referenci swanctl.conf existuje právě proto, aby toto řazení bylo záměrné. Bez něj přesunutí bloku změní chování. Proto se také dvě konfigurace, které na papíře vypadají rovnocenně, mohou chovat v opačném pořadí.

Toto pravidlo řazení vytváří režim selhání, který stojí za zapamatování. Druhý blok remote není další přijatelná možnost; je to druhý požadavek, a proto se zásada, která se čte jako buď/anebo, chová jako a-pak. Zásada brány může přijmout certifikát zapsaného počítače a poté vyžadovat výměnu EAP toho uživatele, v tomto pořadí.

Rozlišujte kola od nezávislých faktorů

Dvě kola nejsou automaticky dva nezávislé faktory. Opakování důkazu nebo držení dvou údajů ve stejném úložišti nedodá sílu, kterou měl návrh přidat. Nezávislost je vlastnost toho, jak jsou tajemství držena a co je kompromituje, ne kolik výměn protokol provede. Návrh, který počítá kola jako faktory, přeceňuje to, co má. Tento rozdíl je nejdůležitější, když otázka souladu klade otázku, kolik faktorů přihlášení skutečně používá.

Certifikát počítače prokazuje držení svého přijatého klíče a nic víc. Není to hardwarová atestace ani zpráva o stavu zařízení, takže zásada, která potřebuje informace o stavu, potřebuje jiný mechanismus. Ani pole subject není inventární štítek, kterému lze věřit, protože subject volí ten, kdo certifikát vydal nebo zapsal. Pokud návrh potřebuje důkaz, že počítač je zdravý, musí tento důkaz přijít z komponenty, která počítač měří.

Než kolo přidáte, zapište, co skutečně prokazuje. Když dvě kola prokazují totéž dvakrát, druhé přidá latenci a tikety podpory místo jistoty. Ta poznámka je také to, co zastaví hádku o tom, zda si další kolo zaslouží svou cenu.

Napište pravidlo párování a otestujte odmítnutí

Rozhodněte, které identity počítačů se smějí párovat s kterými lidmi, a napište pravidlo tam, kde žije vynucení. Dva platné údaje vedle sebe neprokazují o párování nic, protože párování je rozhodnutí o autorizaci, ne výsledek ověření. Registrační záznamy nebo backend ověřování musí vztah, který organizace chce, vynutit.

Potom otestujte, co má selhat: přijatý uživatel na neschváleném počítači, neschválený uživatel s údajem počítače a protějšek, který nedokáže provést další kolo. Pokud všichni tři tiše dostanou stejný přístup, zásada popisuje záměr, místo aby ho vynucovala. Porovnejte deklarovanou konfiguraci s tím, co hlásí démon, protože spojení, které nikdy neodpovídalo, vypadá stejně jako pravidlo, které prošlo:

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

Kontrolujte vyjednaná kola a výslednou autorizaci, ne jen úspěšné přihlášení. A nesahejte po starých nastaveních IKEv1 XAuth jako po zkratce: slaďte protokol, role, pořadí a skutečné chování klienta, místo abyste mazali požadované kolo, dokud spojení neuspěje. Smazání kola, které selhává, je způsob, jak se návrh se dvěma důkazy tiše stane návrhem s jedním důkazem, který nikdo nezkontroloval. Smazání ponechte v záznamu změn.