Két identitás egy IKEv2-bejelentkezésben: először a gép, aztán a felhasználó

Egy ügyféltanúsítvány érvényesül, az első csere lefut, majd a kapcsolat leáll egy további hitelesítési körre vonatkozó hibával. A tanúsítványláncban semmi sem hibás, és a hálózatban semmi sem változott. Az átjáró úgy van beállítva, hogy második bizonyítékot követeljen a csatlakozó oldaltól, az ügyfél pedig soha nem küld egyet. Eldönteni, ki mit bizonyít, és milyen sorrendben, maga a teljes feladat, és azzal kezdődik, hogy kiolvassuk a szabályzatot arról a végpontról, amelyen állunk. Két különböző fajtájú bizonyíték rögzített sorrendben tervezési döntés, nem jelölőnégyzet.

A tünet: sikertelen folytatás egy sikeres első bizonyíték után

Az első csere lefut, és a napló egészségesnek látszik, amíg az átjáró EAP-n keresztül felhasználói identitást nem kér. Ekkor a kézfogás elakad, vagy a további kört megnevező protokollhibát ad vissza. Egy teljesen érvényes géptanúsítvány olyan okból utasítódik el, amelynek semmi köze az érvényességéhez. A szabályzat második bizonyítékot kért, és az ügyfél válasza soha nem érkezett meg.

A kudarc mindkét leírása pontos attól függően, hol állunk. Az ügyfél oldaláról úgy néz ki, hogy egy kiszolgáló érvényes tanúsítványt utasít el, a kiszolgáló oldaláról pedig úgy, hogy egy ügyfél nem tudja befejezni a bejelentkezést. Ugyanaz az esemény az egyik naplóban bizalmi problémaként, a másikban képességproblémaként olvasható. Csak a beállított szabályzat mondja meg, melyik.

Mit tesz hozzá a kiterjesztés, és mit nem

Az IKEv2 egy kiterjesztést hordoz arra, hogy egyetlen munkameneten belül több hitelesítési cserét futtasson. Az RFC 4739 többek között olyan sorrendet vázol fel, amelyben az ügyfél tanúsítványidentitást bizonyít, majd EAP-n keresztül hitelesít egy személyt. A dokumentum státusza Experimental, ami azt jelenti, hogy egyetlen implementáció sem tartozik nekünk ezzel a funkcióval. Ne tételezzünk fel semmit a támogatásról, amíg a partner meg nem tárgyalja.

Mindkét félnek támogatnia kell a kiterjesztést, és meg kell egyeznie benne a csere során. Egy második körre beállított átjáró nem kényszeríthet egy ügyfelet, hogy végrehajtson egyet, és az azt támogató ügyfél nem használja, hacsak a kiszolgáló nem kéri. Ez az aszimmetria az oka annak, hogy a kudarc általában időtúllépésként vagy protokollhibaként jelenik meg a képességről szóló egyértelmű nyilatkozat helyett. Az egyik oldal konfigurációjának elolvasása a történések felét mondja meg.

Végpontonként egy bizonyíték a szokásos forma, és ez nem ez a terv. Az átjáró bemutatja a tanúsítványát, a felhasználó EAP-val válaszol, és mindkét oldal pontosan egyszer hitelesítette a másikat. Ez a két bizonyíték ellentétes végpontokról érkezik, így egyik sem mond külön bármit a gépről és a használó személyről.

Az EAP-TLS harmadik forma, és az sem ez. Ott az ügyféltanúsítvány egy EAP-módszeren belül kerül bemutatásra, így az ügyfél mégis egyetlen IKE-hitelesítést végez. A hitelesítő adatok azonosnak tűnhetnek a többkörös esettel, miközben a protokoll egy kört hordoz kettő helyett. Ezért bukik el az EAP-TLS-telepítésből másolt terv pontosan ott, ahol a második bizonyítékot várják.

Ugyanaz a fájl másként olvasható az átjárón

Ugyanaz a swanctl-fájl másként olvasható attól függően, hol fut, és ez az a rész, amin az emberek elcsúsznak. A laptopon az átjáró a partner, az átjárón pedig a laptop, ezért a local oldalt úgy írjuk, hogy ki vagyok én, a remote oldalt pedig úgy, hogy kit fogadok el. A local blokk leírja, hogyan hitelesíti magát ez a végpont, a remote blokk pedig megadja, mit követel a másik végtől. Egy blokk átmásolása a két fájl között megfordítja a jelentését anélkül, hogy egyetlen karaktert is megváltoztatna. A két fájl összehasonlítása szinte semmit sem mond, mert ugyanazok a szavak mindegyikben az ellenkezőjét jelentik.

Egy szakasz helye határozza meg a sorrendjét, hacsak egy körszám felül nem írja. Ezért a további local vagy remote szakaszok további köröket írnak le, nem alternatívákat, és a swanctl.conf-referencia dokumentumban szereplő kifejezett körszám éppen azt szolgálja, hogy ez a sorrend szándékos legyen. Nélküle egy blokk mozgatása megváltoztatja a viselkedést. Ezért viselkedhet két papíron egyenértékűnek tűnő konfiguráció ellentétes sorrendben.

Ez a sorrendszabály hozza létre azt a hibaállapotot, amelyet érdemes megjegyezni. A második remote blokk nem egy másik elfogadható lehetőség; ez egy második követelmény, ezért a vagy/vagy-ként olvasott szabályzat és-utána módjára viselkedik. Egy átjárószabályzat elfogadhatja a regisztrált gép tanúsítványát, majd megkövetelheti annak a felhasználónak az EAP-cseréjét, ebben a sorrendben.

Különböztessük meg a köröket a független tényezőktől

Két kör nem automatikusan két független tényező. Egy bizonyíték megismétlése, vagy két hitelesítő adat tárolása ugyanabban a tárolóban, nem adja azt az erőt, amelyet a tervnek hozzá kellett volna tennie. A függetlenség annak tulajdonsága, hogyan őrzik a titkokat, és mi teszi azokat sebezhetővé, nem pedig azé, hogy a protokoll hány cserét futtat. Az a terv, amely a köröket tényezőként számolja, túlbecsüli azt, amije van. Ez a különbség akkor a legfontosabb, amikor egy megfelelőségi kérdés azt kérdezi, hány tényezőt használ a bejelentkezés valójában.

A géptanúsítvány az elfogadott kulcs birtoklását bizonyítja, és semmi többet. Nem hardveres attestation és nem eszköz-egészségügyi jelentés, ezért az állapotinformációt igénylő szabályzatnak más mechanizmusra van szüksége. A subject mező sem megbízható leltárcímke, mert a subjectet az választja, aki kiállította vagy regisztrálta a tanúsítványt. Ha a tervnek bizonyíték kell arról, hogy a gép egészséges, annak a bizonyítéknak a gépet mérő komponensből kell jönnie.

Írjuk le, mit bizonyít valójában az egyes kör, mielőtt hozzáadjuk. Amikor két kör ugyanazt kétszer bizonyítja, a második késleltetést és támogatási jegyeket ad hozzá a bizonyosság helyett. Ez a feljegyzés az is, ami megállítja a vitát arról, hogy a további kör megéri-e a költségét.

Írjuk meg a párosítási szabályt, és teszteljük az elutasításokat

Döntsük el, mely gépidentitások párosulhatnak mely személyekkel, és írjuk meg a szabályt ott, ahol az érvényesítés él. Két érvényes hitelesítő adat egymás mellett semmit sem bizonyít a párosításról, mert a párosítás engedélyezési döntés, nem hitelesítési eredmény. A regisztrációs nyilvántartásnak vagy a hitelesítési háttérrendszernek kell érvényesítenie azt a kapcsolatot, amelyet a szervezet szeretne.

Aztán teszteljük, minek kell elbuknia: egy elfogadott felhasználó egy nem jóváhagyott gépen, egy nem jóváhagyott felhasználó a gép hitelesítő adatával, és egy partner, amely nem tudja végrehajtani a további kört. Ha mindhárom csendesen ugyanazt a hozzáférést kapja, a szabályzat szándékot ír le ahelyett, hogy érvényesítené. Hasonlítsuk össze a deklarált konfigurációt azzal, amit a démon jelent, mert a soha nem illeszkedő kapcsolat ugyanúgy néz ki, mint egy átment szabály:

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

Ellenőrizzük a kialkudott köröket és az abból következő engedélyezést, ne csak a sikeres bejelentkezést. És ne nyúljunk a régi IKEv1 XAuth-beállításokhoz rövidítésként: illesszük a protokollhoz, a szerepekhez, a sorrendhez és az ügyfél valódi viselkedéséhez, ahelyett hogy törölnénk egy szükséges kört, amíg egy kapcsolat létre nem jön. A bukó kör törlése az az út, amelyen egy két bizonyítékos terv csendesen egy senki által nem ellenőrzött egy bizonyítékos tervvé válik. Tartsuk a törlést a változási nyilvántartásban.