Twee identiteite in een IKEv2-aanmelding: eers die masjien, dan die gebruiker

'n Kliëntsertifikaat verifieer, die eerste uitruiling voltooi, en dan stop die verbinding met 'n fout oor 'n bykomende verifikasiestap. Niks in die sertifikaatketting is verkeerd nie en niks in die netwerk het verander nie. Die gateway is opgestel om 'n tweede bewys van die verbindende kant te eis, en die kliënt stuur nooit een nie. Om te besluit wie wat bewys, in watter volgorde, is die hele taak, en dit begin by die lees van die beleid vanaf die eindpunt waar jy staan. Twee bewyste van verskillende soorte, in 'n vaste volgorde, is 'n ontwerpbesluit eerder as 'n keuseblokkie.

Die simptoom: mislukking ná 'n geslaagde eerste bewys

Die eerste uitruiling voltooi en die log lyk gesond, totdat die gateway 'n gebruikeridentiteit deur EAP vra. Die handdruk staak dan of lewer 'n protokolfout wat die ekstra rondte noem. 'n Heeltemal geldige masjiensertifikaat word verwerp om 'n rede wat niks met sy geldigheid te doen het nie. Die beleid het 'n tweede bewys gevra, en die kliënt se antwoord het nooit gekom nie.

Albei beskrywings van daardie mislukking is akkuraat, afhangend van waar jy staan. Van die kliënt se kant lyk dit of 'n bediener 'n geldige sertifikaat verwerp, en van die bediener se kant lyk dit of 'n kliënt nie die aanmelding kan voltooi nie. Dieselfde gebeurtenis lees as 'n vertrouensprobleem in die een log en 'n vermoëprobleem in die ander. Net die opgestelde beleid sê vir jou watter een dit is.

Wat die uitbreiding byvoeg, en wat nie

IKEv2 dra 'n uitbreiding om meer as een verifikasie-uitruiling binne 'n enkele sessie te doen. RFC 4739 skets, onder andere rye, 'n kliënt wat 'n sertifikaatidentiteit bewys en dan 'n persoon deur EAP verifieer. Die dokument is Eksperimenteel, wat beteken geen implementering is jou die funksie verskuldig nie. Neem niks aan oor ondersteuning voordat die eweknie dit onderhandel nie.

Albei kante moet die uitbreiding ondersteun en tydens die uitruiling daaroor saamstem. 'n Gateway wat vir 'n tweede rondte opgestel is, kan nie 'n kliënt dwing om een uit te voer nie, en 'n kliënt wat dit ondersteun, sal dit nie gebruik tensy die bediener dit vra nie. Daardie asimmetrie is waarom die mislukking gewoonlik as 'n tydsverloop of 'n protokolfout opduik eerder as 'n duidelike verklaring oor vermoë. Om een kant se opstelling te lees, vertel jou die helfte van wat gaan gebeur.

Een bewys per eindpunt is die normale vorm, en dit is nie hierdie ontwerp nie. Die gateway wys sy sertifikaat, die gebruiker antwoord EAP, en elke kant het die ander presies een keer verifieer. Daardie twee bewyste kom van teenoorgestelde eindpunte, so nie een sê iets afsonderlik oor die masjien en die persoon wat dit gebruik nie.

EAP-TLS is 'n derde vorm, en dit is ook nie hierdie een nie. Daar word 'n kliëntsertifikaat binne 'n EAP-metode aangebied, so die kliënt voltooi steeds 'n enkele IKE-verifikasie. Die geloofsbriewe kan identies lyk aan die meerrondte-geval terwyl die protokol een rondte eerder as twee dra. Dit is waarom 'n ontwerp wat uit 'n EAP-TLS-ontplooiing gekopieer is, misluk op die punt waar die tweede bewys verwag word.

Dieselfde lêer lees anders op die gateway

Dieselfde swanctl-lêer lees anders na gelang van waar dit loop, en dit is die deel wat mense laat struikel. Op die skootrekenaar is die gateway die eweknie, en op die gateway is die skootrekenaar dit, so skryf die local-kant as wie ek is en die remote-kant as wie ek sal aanvaar. 'n local-blok beskryf hoe hierdie eindpunt homself verifieer, en 'n remote-blok sê wat dit van die ander kant vereis. Om 'n blok tussen die twee lêers te kopieer, keer die betekenis om sonder om 'n enkele karakter te verander. Om die twee lêers te vergelyk, sê byna niks, want dieselfde woorde beteken in elkeen die teenoorgestelde.

Die posisie van 'n afdeling bepaal sy volgorde, tensy 'n rondtenommer dit oorheers. Bykomende local- of remote-afdelings beskryf dus bykomende rondtes eerder as alternatiewe, en die eksplisiete rondtenommer in die swanctl.conf-verwysing bestaan juis om daardie ordening doelbewus te maak. Sonder dit verander die skuif van 'n blok die gedrag. Dit is ook waarom twee opstellings wat op papier gelykwaardig lyk, in teenoorgestelde volgordes kan werk.

Daardie ordeningsreël lewer die mislukkingsmodus wat die moeite werd is om te onthou. 'n Tweede remote-blok is nie nog 'n aanvaarbare opsie nie; dit is 'n tweede eis, en daarom gedra 'n beleid wat soos óf/of lees, hom soos en-dan. 'n Gateway-beleid kan die sertifikaat van die ingeskrewe masjien aanvaar en dan daardie gebruiker se EAP-uitruiling vereis, in daardie volgorde.

Onderskei rondtes van onafhanklike faktore

Twee rondtes is nie outomaties twee onafhanklike faktore nie. Om 'n bewys te herhaal, of twee geloofsbriewe in dieselfde stoor te hou, lewer nie die sterkte wat die ontwerp veronderstel was om by te voeg nie. Onafhanklikheid is 'n eienskap van hoe die geheime gehou word en wat hulle kompromitteer, nie van hoeveel uitruilings die protokol loop nie. 'n Ontwerp wat rondtes as faktore tel, oorskat wat dit het. Daardie onderskeid maak die meeste saak wanneer 'n voldoeningsvraag vra hoeveel faktore die aanmelding werklik gebruik.

'n Masjiensertifikaat bewys besit van sy aanvaarde sleutel, en niks meer nie. Dit is nie 'n hardeware-attestasie en nie 'n toestelgesondheidsverslag nie, so 'n beleid wat postuurinligting nodig het, het 'n ander meganisme nodig. Die subject-veld is ook nie 'n voorraadetiket wat jy kan vertrou nie, want die subject word gekies deur wie die sertifikaat uitgereik of ingeskryf het. As die ontwerp bewys nodig het dat die masjien gesond is, moet daardie bewys van 'n komponent kom wat die masjien meet.

Skryf neer wat elke rondte werklik bewys voordat jy dit byvoeg. Wanneer twee rondtes dieselfde ding twee keer bewys, voeg die tweede een latensie en ondersteuningskaartjies by eerder as versekering. Daardie nota is ook wat 'n argument stop oor of die ekstra rondte sy koste verdien.

Skryf die paringsreël en toets die weierings

Besluit watter masjienidentiteite met watter mense mag paar, en skryf die reël waar die handhawing woon. Twee geldige geloofsbriewe wat langs mekaar sit, bewys niks oor die paring nie, want die paring is 'n magtigingsbesluit eerder as 'n verifikasie-uitkoms. Die inskrywingsrekords of die verifikasie-agterkant moet die verhouding handhaaf wat die organisasie wil hê.

Toets dan wat moet misluk: 'n aanvaarde gebruiker op 'n nie-goedgekeurde masjien, 'n nie-goedgekeurde gebruiker wat die masjien se geloofsbrief het, en 'n eweknie wat nie die bykomende rondte kan uitvoer nie. As al drie stilweg dieselfde toegang kry, beskryf die beleid 'n bedoeling eerder as om een af te dwing. Vergelyk die verklaarde opstelling met wat die daemon rapporteer, want 'n verbinding wat nooit gepas het nie, lyk identies aan 'n reël wat geslaag het:

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

Kontroleer die onderhandelde rondtes en die gevolglike magtiging, nie net die geslaagde aanmelding nie. En moenie na legacy IKEv1 XAuth-instellings gryp as 'n kortpad nie: pas die protokol, die rolle, die volgorde en die kliënt se werklike gedrag aan, eerder as om 'n vereiste rondte te skrap totdat 'n verbinding slaag. Om die rondte te skrap wat misluk, is hoe 'n twee-bewys-ontwerp stilweg 'n een-bewys-ontwerp word wat niemand hersien het nie. Hou die skrapping in die veranderingsrekord.