Două identități într-o singură autentificare IKEv2: mai întâi mașina, apoi utilizatorul

Un certificat de client este validat, primul schimb se încheie, iar apoi conexiunea se oprește cu o eroare despre o rundă suplimentară de autentificare. Nimic din lanțul de certificate nu este greșit și nimic din rețea nu s-a schimbat. Gateway-ul este configurat să ceară o a doua dovadă de la partea care se conectează, iar clientul nu trimite niciodată una. A decide cine dovedește ce, și în ce ordine, este întreaga sarcină, și începe prin a citi politica din punctul final pe care stați. Două dovezi de tipuri diferite, într-o ordine fixă, sunt o decizie de proiectare și nu o casetă de bifare.

Simptomul: eșec după o primă dovadă reușită

Primul schimb se încheie și jurnalul pare sănătos, până când gateway-ul cere o identitate de utilizator prin EAP. Atunci strângerea de mână se blochează sau returnează o eroare de protocol care numește runda suplimentară. Un certificat de mașină perfect valid este respins dintr-un motiv care nu are nimic de-a face cu valabilitatea lui. Politica cerea o a doua dovadă, iar răspunsul clientului nu a ajuns niciodată.

Ambele descrieri ale acelui eșec sunt exacte în funcție de locul unde stați. Din partea clientului pare un server care respinge un certificat valid, iar din partea serverului pare un client care nu poate termina autentificarea. Același eveniment se citește ca o problemă de încredere într-un jurnal și o problemă de capacitate în celălalt. Doar politica configurată vă spune care dintre ele este.

Ce adaugă extensia și ce nu adaugă

IKEv2 poartă o extensie pentru a rula mai mult de un schimb de autentificare într-o singură sesiune. RFC 4739 schițează, printre alte secvențe, un client care dovedește o identitate de certificat și apoi autentifică o persoană prin EAP. Documentul are statutul Experimental, ceea ce înseamnă că nicio implementare nu vă datorează această funcție. Nu presupuneți nimic despre suport până când partenerul nu negociază.

Ambele părți trebuie să sprijine extensia și să fie de acord cu ea în timpul schimbului. Un gateway configurat pentru o a doua rundă nu poate obliga un client să execute una, iar un client care o sprijină nu o va folosi dacă serverul nu o cere. Această asimetrie este motivul pentru care eșecul apare de obicei ca un timeout sau o eroare de protocol în locul unei declarații clare despre capacitate. Citirea configurației unei singure părți vă spune jumătate din ce se va întâmpla.

O dovadă pe punct final este forma normală, iar acesta nu este acel proiect. Gateway-ul își prezintă certificatul, utilizatorul răspunde prin EAP, iar fiecare parte a autentificat cealaltă exact o dată. Acele două dovezi vin din puncte finale opuse, deci niciuna nu spune ceva separat despre mașină și persoana care o folosește.

EAP-TLS este o a treia formă, și nici aceasta nu este aceea. Acolo un certificat de client este prezentat în interiorul unei metode EAP, deci clientul finalizează totuși o singură autentificare IKE. Acreditările pot arăta identic cu cazul cu mai multe runde, în timp ce protocolul poartă o rundă în loc de două. De aceea un proiect copiat dintr-o instalare EAP-TLS eșuează exact în punctul în care se așteaptă a doua dovadă.

Același fișier se citește altfel pe gateway

Același fișier swanctl se citește altfel în funcție de locul unde rulează, și aceasta este partea care îi face pe oameni să se împiedice. Pe laptop gateway-ul este partenerul, iar pe gateway laptopul este partenerul, așa că scrieți partea local ca cine sunt eu și partea remote ca pe cine voi accepta. Un bloc local descrie cum se autentifică acest punct final, iar un bloc remote arată ce cere de la celălalt capăt. Copierea unui bloc între cele două fișiere îi inversează sensul fără a schimba un singur caracter. Compararea celor două fișiere nu vă spune aproape nimic, pentru că aceleași cuvinte înseamnă lucruri opuse în fiecare.

Poziția unei secțiuni îi stabilește ordinea, dacă nu este depășită de un număr de rundă. De aceea secțiunile local sau remote suplimentare descriu runde suplimentare și nu alternative, iar numărul explicit de rundă din referința swanctl.conf există exact pentru a face acea ordine deliberată. Fără el, mutarea unui bloc schimbă comportamentul. De aceea și două configurații care par echivalente pe hârtie se pot comporta în ordini opuse.

Acea regulă de ordine produce modul de eșec care merită reținut. Un al doilea bloc remote nu este o altă opțiune acceptabilă; este o a doua cerință, de aceea o politică ce se citește ca sau/sau se comportă ca și-apoi. O politică de gateway poate accepta certificatul mașinii înregistrate și apoi cere schimbul EAP al acelui utilizator, în acea ordine.

Distingeți rundele de factorii independenți

Două runde nu sunt automat doi factori independenți. Repetarea unei dovezi, sau păstrarea a două acreditări în același depozit, nu oferă puterea pe care proiectul trebuia să o adauge. Independența este o proprietate a modului în care sunt păstrate secretele și a ceea ce le compromite, nu a numărului de schimburi pe care le execută protocolul. Un proiect care numără rundele ca factori supraestimează ce are. Această distincție contează cel mai mult când o întrebare de conformitate întreabă câți factori folosește autentificarea de fapt.

Un certificat de mașină dovedește posedarea cheii sale acceptate, și nimic mai mult. Nu este o atestare hardware și nici un raport de sănătate al dispozitivului, așa că o politică ce are nevoie de informații de postură are nevoie de alt mecanism. Nici câmpul subject nu este o etichetă de inventar de încredere, pentru că subject este ales de cine a emis sau a înregistrat certificatul. Dacă proiectul are nevoie de o dovadă că mașina este sănătoasă, acea dovadă trebuie să vină de la o componentă care măsoară mașina.

Notați ce dovedește fiecare rundă în realitate înainte de a o adăuga. Când două runde dovedesc același lucru de două ori, a doua adaugă latență și tichete de suport în loc de certitudine. Acea notă este și ceea ce oprește o dezbatere despre dacă runda suplimentară își merită costul.

Scrieți regula de împerechere și testați refuzurile

Decideți ce identități de mașină se pot împerechea cu ce persoane, și scrieți regula acolo unde trăiește aplicarea. Două acreditări valide una lângă alta nu dovedesc nimic despre împerechere, pentru că împerecherea este o decizie de autorizare și nu un rezultat al autentificării. Înregistrările de inscriere sau backend-ul de autentificare trebuie să aplice relația pe care organizația o vrea.

Apoi testați ce ar trebui să eșueze: un utilizator acceptat pe o mașină neaprobată, un utilizator neaprobat care deține acreditarea mașinii și un partener care nu poate executa runda suplimentară. Dacă toate trei primesc în tăcere același acces, politica descrie o intenție în loc să o aplice. Comparați configurația declarată cu ce raportează daemonul, pentru că o conexiune care nu s-a potrivit niciodată arată identic cu o regulă care a trecut:

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

Verificați rundele negociate și autorizarea care rezultă, nu doar autentificarea reușită. Și nu apelați la setări vechi IKEv1 XAuth ca scurtătură: potriviți protocolul, rolurile, ordinea și comportamentul real al clientului în loc să ștergeți o rundă necesară până când o conexiune reușește. Ștergerea rundei care eșuează este felul în care un proiect cu două dovezi devine în tăcere un proiect cu o singură dovadă pe care nimeni nu l-a revizuit. Păstrați ștergerea în registrul de modificări.