Dwie tożsamości w jednym logowaniu IKEv2: najpierw maszyna, potem użytkownik

Certyfikat klienta zostaje zweryfikowany, pierwsza wymiana się kończy, a potem połączenie zatrzymuje się z błędem o dodatkowej rundzie uwierzytelniania. W łańcuchu certyfikatów nie ma nic złego i nic w sieci się nie zmieniło. Brama jest skonfigurowana tak, by żądać drugiego dowodu od strony, która się łączy, a klient nigdy go nie wysyła. Rozstrzygnięcie, kto co dowodzi i w jakiej kolejności, to całe zadanie, i zaczyna się od odczytania polityki z punktu końcowego, na którym stoisz. Dwa dowody różnego rodzaju, w ustalonej kolejności, to decyzja projektowa, a nie pole wyboru.

Objaw: błąd po udanym pierwszym dowodzie

Pierwsza wymiana się kończy i log wygląda zdrowo, dopóki brama nie poprosi o tożsamość użytkownika przez EAP. Wtedy uścisk dłoni się zatrzymuje albo wraca błąd protokołu, który nazywa dodatkową rundę. Całkowicie ważny certyfikat maszyny jest odrzucany z powodu, który nie ma nic wspólnego z jego ważnością. Polityka żądała drugiego dowodu, a odpowiedź klienta nigdy nie dotarła.

Oba opisy tego błędu są trafne w zależności od tego, gdzie stoisz. Ze strony klienta wygląda to jak serwer odrzucający ważny certyfikat, a ze strony serwera jak klient, który nie potrafi dokończyć logowania. To samo zdarzenie czyta się jako problem zaufania w jednym logu i problem możliwości w drugim. Tylko skonfigurowana polityka mówi, który to.

Co rozszerzenie dodaje, a czego nie

IKEv2 niesie rozszerzenie pozwalające przeprowadzić więcej niż jedną wymianę uwierzytelniania w jednej sesji. RFC 4739 szkicuje, obok innych sekwencji, klienta, który dowodzi tożsamości certyfikatu, a następnie uwierzytelnia osobę przez EAP. Dokument ma status Experimental, co znaczy, że żadna implementacja nie jest ci winna tej funkcji. Nie zakładaj nic o wsparciu, dopóki partner go nie wynegocjuje.

Obie strony muszą obsługiwać rozszerzenie i uzgodnić je podczas wymiany. Brama skonfigurowana pod drugą rundę nie może zmusić klienta do jej wykonania, a klient, który je obsługuje, nie użyje go, jeśli serwer o to nie poprosi. Ta asymetria jest powodem, dla którego błąd zwykle objawia się jako przekroczenie czasu albo błąd protokołu, a nie jako jasne oświadczenie o możliwościach. Przeczytanie konfiguracji jednej strony mówi ci połowę tego, co się stanie.

Jeden dowód na punkt końcowy to normalna forma i to nie jest ten projekt. Brama przedstawia swój certyfikat, użytkownik odpowiada przez EAP, a każda strona uwierzytelniła drugą dokładnie raz. Te dwa dowody pochodzą z przeciwnych punktów końcowych, więc żaden nie mówi osobno nic o maszynie i osobie, która jej używa.

EAP-TLS to trzecia forma i ona też nie jest tą. Tam certyfikat klienta jest przedstawiany wewnątrz metody EAP, więc klient nadal kończy jedno uwierzytelnienie IKE. Poświadczenia mogą wyglądać identycznie jak w przypadku wielu rund, podczas gdy protokół niesie jedną rundę zamiast dwóch. Dlatego projekt skopiowany z wdrożenia EAP-TLS zawodzi dokładnie w miejscu, w którym oczekuje się drugiego dowodu.

Ten sam plik czyta się inaczej na bramie

Ten sam plik swanctl czyta się inaczej w zależności od tego, gdzie działa, i to jest część, na której ludzie się potykają. Na laptopie brama jest partnerem, a na bramie partnerem jest laptop, więc pisz stronę local jako kim jestem, a stronę remote jako kogo przyjmę. Blok local opisuje, jak ten punkt końcowy uwierzytelnia siebie, a blok remote mówi, czego wymaga od drugiego końca. Skopiowanie bloku między dwoma plikami odwraca jego znaczenie bez zmiany jednego znaku. Porównanie obu plików nie mówi ci prawie nic, bo te same słowa znaczą w każdym z nich coś przeciwnego.

Położenie sekcji ustala jej kolejność, chyba że nadpisze ją numer rundy. Dlatego dodatkowe sekcje local lub remote opisują dodatkowe rundy, a nie alternatywy, a jawny numer rundy w dokumentacji swanctl.conf istnieje właśnie po to, by ta kolejność była zamierzona. Bez niego przeniesienie bloku zmienia zachowanie. Dlatego też dwie konfiguracje, które na papierze wyglądają równoważnie, mogą działać w przeciwnej kolejności.

Ta reguła kolejności wytwarza tryb awarii, który warto zapamiętać. Drugi blok remote nie jest kolejną dopuszczalną opcją; to drugie żądanie, dlatego polityka czytana jako albo/albo zachowuje się jak i-potem. Polityka bramy może przyjąć certyfikat zarejestrowanej maszyny, a następnie zażądać wymiany EAP tego użytkownika, w tej kolejności.

Odróżnij rundy od niezależnych czynników

Dwie rundy nie są automatycznie dwoma niezależnymi czynnikami. Powtarzanie dowodu albo trzymanie dwóch poświadczeń w tym samym magazynie nie daje siły, którą projekt miał dodać. Niezależność jest właściwością tego, jak przechowywane są sekrety i co je kompromituje, a nie tego, ile wymian wykonuje protokół. Projekt, który liczy rundy jako czynniki, przecenia to, co ma. To rozróżnienie ma największe znaczenie, gdy pytanie o zgodność pyta, ilu czynników logowanie naprawdę używa.

Certyfikat maszyny dowodzi posiadania swojego przyjętego klucza i niczego więcej. To nie jest atestacja sprzętowa ani raport o zdrowiu urządzenia, więc polityka potrzebująca informacji o stanie potrzebuje innego mechanizmu. Pole subject też nie jest wiarygodną etykietą inwentarzową, bo subject wybiera ten, kto wydał lub zarejestrował certyfikat. Jeśli projekt potrzebuje dowodu, że maszyna jest zdrowa, ten dowód musi pochodzić od komponentu, który mierzy maszynę.

Zapisz, czego każda runda naprawdę dowodzi, zanim ją dodasz. Gdy dwie rundy dowodzą tego samego dwa razy, druga dodaje opóźnienie i zgłoszenia do wsparcia zamiast pewności. Ta notatka jest też tym, co zatrzymuje spór o to, czy dodatkowa runda jest warta swojego kosztu.

Napisz regułę parowania i przetestuj odmowy

Zdecyduj, które tożsamości maszyn mogą być parowane z którymi osobami, i zapisz regułę tam, gdzie żyje egzekwowanie. Dwa ważne poświadczenia obok siebie nie dowodzą niczego o parowaniu, bo parowanie jest decyzją autoryzacyjną, a nie wynikiem uwierzytelnienia. Rekordy rejestracji albo backend uwierzytelniania muszą egzekwować relację, której chce organizacja.

Potem przetestuj to, co powinno zawieść: zaakceptowany użytkownik na niezatwierdzonej maszynie, niezatwierdzony użytkownik z poświadczeniem maszyny i partner, który nie potrafi wykonać dodatkowej rundy. Jeśli wszystkie trzy po cichu dostają ten sam dostęp, polityka opisuje zamiar, a nie egzekwuje go. Porównaj zadeklarowaną konfigurację z tym, co raportuje demon, bo połączenie, które nigdy nie pasowało, wygląda identycznie jak reguła, która przeszła:

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

Sprawdź wynegocjowane rundy i wynikającą z nich autoryzację, nie tylko udane logowanie. I nie sięgaj po stare ustawienia IKEv1 XAuth jako skrót: dopasuj protokół, role, kolejność i rzeczywiste zachowanie klienta, zamiast usuwać wymaganą rundę, aż połączenie się uda. Usunięcie rundy, która zawodzi, to sposób, w jaki projekt z dwoma dowodami po cichu staje się projektem z jednym dowodem, którego nikt nie przejrzał. Zatrzymaj usunięcie w rejestrze zmian.