Dve identity v jednom prihlásení IKEv2: najprv stroj, potom používateľ

Klientsky certifikát sa overí, prvá výmena sa dokončí a potom sa spojenie zastaví s chybou o ďalšom kole overovania. V reťazci certifikátov nie je nič nesprávne a v sieti sa nič nezmenilo. Brána je nastavená tak, aby od pripájajúcej sa strany vyžadovala druhý dôkaz, a klient ho nikdy neodošle. Rozhodnúť, kto čo dokazuje a v akom poradí, je celá úloha, a začína sa prečítaním politiky z koncového bodu, na ktorom stojíte. Dva dôkazy rôzneho druhu v pevnom poradí sú návrhové rozhodnutie, nie zaškrtávacie políčko.

Príznak: zlyhanie po úspešnom prvom dôkaze

Prvá výmena sa dokončí a log vyzerá zdravo, kým brána nevyžiada identitu používateľa cez EAP. Potom sa handshake zasekne alebo vráti chybu protokolu, ktorá pomenuje ďalšie kolo. Úplne platný certifikát stroja sa odmietne z dôvodu, ktorý nemá nič spoločné s jeho platnosťou. Politika žiadala druhý dôkaz a odpoveď klienta nikdy nedorazila.

Oba popisy tohto zlyhania sú presné podľa toho, kde stojíte. Z pohľadu klienta to vyzerá ako server, ktorý odmieta platný certifikát, a z pohľadu servera ako klient, ktorý nedokáže dokončiť prihlásenie. Tá istá udalosť sa v jednom logu číta ako problém dôvery a v druhom ako problém schopností. Iba nastavená politika vám povie, ktorý z nich to je.

Čo rozšírenie pridáva a čo nie

IKEv2 nesie rozšírenie na vykonanie viac ako jednej výmeny overovania v rámci jednej relácie. RFC 4739 načrtáva, popri iných sekvenciách, klienta, ktorý dokáže identitu certifikátom a potom overí osobu cez EAP. Dokument má status Experimental, čo znamená, že žiadna implementácia vám túto funkciu nedlží. Nepredpokladajte nič o podpore, kým to partner nevyjedná.

Obe strany musia rozšírenie podporovať a dohodnúť sa na ňom počas výmeny. Brána nastavená na druhé kolo nemôže klienta prinútiť, aby ho vykonal, a klient, ktorý ho podporuje, ho nepoužije, ak o to server nepožiada. Práve táto asymetria je dôvod, prečo sa zlyhanie zvyčajne prejaví ako časový limit alebo chyba protokolu namiesto jasného vyhlásenia o schopnostiach. Prečítanie konfigurácie jednej strany vám povie polovicu toho, čo sa stane.

Jeden dôkaz na koncový bod je bežná forma a toto nie je ten návrh. Brána predloží svoj certifikát, používateľ odpovie cez EAP a každá strana overila tú druhú presne raz. Tie dva dôkazy pochádzajú z opačných koncových bodov, takže ani jeden z nich nehovorí nič samostatné o stroji a človeku, ktorý ho používa.

EAP-TLS je tretia forma a ani to nie je tento prípad. Tam sa klientsky certifikát predkladá vo vnútri metódy EAP, takže klient stále dokončí jedno overenie IKE. Prihlasovacie údaje môžu vyzerať rovnako ako v prípade viacerých kôl, zatiaľ čo protokol nesie jedno kolo namiesto dvoch. Preto návrh skopírovaný z nasadenia EAP-TLS zlyháva presne v bode, kde sa očakáva druhý dôkaz.

Ten istý súbor sa na bráne číta inak

Ten istý súbor swanctl sa číta inak podľa toho, kde beží, a to je časť, na ktorej ľudia zakopnú. Na notebooku je protistranou brána a na bráne je protistranou notebook, takže stranu local píšte ako kým som a stranu remote ako koho prijmem. Blok local opisuje, ako sa tento koncový bod overuje, a blok remote uvádza, čo vyžaduje od druhého konca. Skopírovanie bloku medzi oboma súbormi obráti jeho význam bez zmeny jediného znaku. Porovnanie oboch súborov vám nepovie takmer nič, pretože tie isté slová v každom z nich znamenajú opak.

Pozícia sekcie určuje jej poradie, ak ho neprebije číslo kola. Dodatočné sekcie local alebo remote preto opisujú ďalšie kolá a nie alternatívy, a výslovné číslo kola v referencii swanctl.conf existuje práve preto, aby toto radenie bolo zámerné. Bez neho premiestnenie bloku zmení správanie. Preto sa aj dve konfigurácie, ktoré na papieri vyzerajú rovnocenné, môžu správať v opačnom poradí.

Toto pravidlo poradia vytvára režim zlyhania, ktorý stojí za zapamätanie. Druhý blok remote nie je ďalšia prijateľná možnosť; je to druhá požiadavka, a preto sa politika, ktorá sa číta ako buď/alebo, správa ako a-potom. Politika brány môže prijať certifikát zapísaného stroja a potom vyžadovať výmenu EAP toho používateľa, v tomto poradí.

Rozlišujte kolá od nezávislých faktorov

Dve kolá nie sú automaticky dva nezávislé faktory. Opakovanie dôkazu alebo držanie dvoch prihlasovacích údajov v tom istom úložisku nedodá silu, ktorú mal návrh pridať. Nezávislosť je vlastnosť toho, ako sa tajomstvá uchovávajú a čo ich kompromituje, nie toho, koľko výmen protokol vykoná. Návrh, ktorý počíta kolá ako faktory, preceňuje to, čo má. Tento rozdiel je najdôležitejší, keď otázka súladu kladie otázku, koľko faktorov prihlásenie skutočne používa.

Certifikát stroja dokazuje držbu svojho prijatého kľúča a nič viac. Nie je to hardvérová atestácia ani správa o zdraví zariadenia, takže politika, ktorá potrebuje informácie o stave, potrebuje iný mechanizmus. Ani pole subject nie je spoľahlivá inventárna značka, pretože subject vyberá ten, kto certifikát vydal alebo zapísal. Ak návrh potrebuje dôkaz, že stroj je zdravý, tento dôkaz musí prísť z komponentu, ktorý stroj meria.

Zapíšte, čo každé kolo skutočne dokazuje, skôr než ho pridáte. Keď dve kolá dokazujú to isté dvakrát, druhé pridá latenciu a tikety podpory namiesto istoty. Tá poznámka je aj to, čo zastaví hádku o tom, či si ďalšie kolo zaslúži svoju cenu.

Napíšte pravidlo párovania a otestujte odmietnutia

Rozhodnite, ktoré identity strojov sa smú párovať s ktorými ľuďmi, a napíšte pravidlo tam, kde žije vynútenie. Dve platné prihlasovacie údaje vedľa seba nedokazujú o párovaní nič, pretože párovanie je rozhodnutie o autorizácii a nie výsledok overenia. Záznamy registrácie alebo backend overovania musia vynútiť vzťah, ktorý organizácia chce.

Potom otestujte, čo má zlyhať: prijatý používateľ na neschválenej mašine, neschválený používateľ s prihlasovacími údajmi stroja a partner, ktorý nedokáže vykonať ďalšie kolo. Ak všetci traja ticho dostanú rovnaký prístup, politika opisuje zámer namiesto toho, aby ho vynucovala. Porovnajte deklarovanú konfiguráciu s tým, čo hlási démon, pretože spojenie, ktoré nikdy neodpovedalo, vyzerá rovnako ako pravidlo, ktoré prešlo:

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

Kontrolujte vyjednané kolá a výslednú autorizáciu, nielen úspešné prihlásenie. A nesiahajte po starých nastaveniach IKEv1 XAuth ako po skratke: zlaďte protokol, roly, poradie a skutočné správanie klienta namiesto vymazania potrebného kola, kým spojenie neuspeje. Vymazanie kola, ktoré zlyháva, je spôsob, akým sa návrh s dvoma dôkazmi ticho stane návrhom s jedným dôkazom, ktorý nikto neskontroloval. Vymazanie ponechajte v zázname zmien.