Twa identiteiten yn ien IKEv2-oanmelding: earst de masine, dan de brûker

In kliïntsertifikaat wurdt falidearre, de earste útwikseling rint ôf, en dan stopt de ferbining mei in flater oer in ekstra autentikaasje-omgong. Der is neat mis yn 'e sertifikaatkeatling en der is neat yn it netwurk feroare. De gateway is konfigurearre om in twadde bewiis fan 'e ferbindende kant te easkjen, en de kliïnt stjoert der nea ien. Beslute wa't wat bewissiget, en yn hokker oarder, is de hiele taak, en it begjint mei it lêzen fan it belied fan it einpunt dêr't jo steane. Twa bewizen fan ferskillende soarte, yn in fêste oarder, is in ûntwerpbeslissing en net in oanfinkfakje.

It symptoom: mislearring nei in suksesfol earste bewiis

De earste útwikseling rint ôf en it logboek liket sûn, oant de gateway in brûkersidentiteit fia EAP freget. Dan stokt de hânskodding of komt der in protokolfout werom dy't de ekstra omgong neamt. In folslein jildich masinesertifikaat wurdt ôfwiisd om in reden dy't neat mei syn jildigens te meitsjen hat. It belied frege om in twadde bewiis, en it antwurd fan 'e kliïnt kaam nea.

Beide beskriuwings fan dy mislearring binne krekt, ôfhinklik fan wêr't jo steane. Fan 'e kliïntkant liket it op in tsjinner dy't in jildich sertifikaat ôfwiist, en fan 'e tsjinnerkant op in kliïnt dy't de oanmelding net ôfmeitsje kin. Deselde barren wurdt yn it iene logboek as in fertrouwensprobleem lêzen en yn it oare as in fermogensprobleem. Allinnich it konfigurearre belied fertelt jo hokker it is.

Wat de útwreiding tafoeget, en wat net

IKEv2 draacht in útwreiding om mear as ien autentikaasje-útwikseling binnen ien sesje te dwaan. RFC 4739 sketst, njonken oare folchoarders, in kliïnt dy't in sertifikaatidentiteit bewissiget en dan in persoan fia EAP autentisearret. It dokumint is Experimental, wat betsjut dat gjin ymplemintaasje jo dy funksje skuldich is. Nim neat oan oer stipe oant de tsjinpartij it ûnderhannelet.

Beide kanten moatte de útwreiding stypje en der by de útwikseling oer iens wurde. In gateway dy't foar in twadde omgong konfigurearre is, kin in kliïnt net twinge om der ien te dwaan, en in kliïnt dy't it stipet sil it net brûke as de tsjinner it net freget. Dy asymmetry is de reden dat de mislearring him meastentiids as in tiidferrin of protokolfout oppenearret ynstee fan as in dúdlike ferklearring oer fermogen. It lêzen fan 'e konfiguraasje fan ien kant fertelt jo de helte fan wat der barre sil.

Ien bewiis per einpunt is de normale foarm, en dit is net dat ûntwerp. De gateway presintearret syn sertifikaat, de brûker antwurdet fia EAP, en elke kant hat de oare krekt ien kear autentisearre. Dy twa bewizen komme fan tsjinoerstelde einpunten, dus net ien seit apart wat oer de masine en de persoan dy't him brûkt.

EAP-TLS is in tredde foarm, en dat is dit ek net. Dêr wurdt in kliïntsertifikaat binnen in EAP-metoade presintearre, dus de kliïnt foltôget noch altyd ien IKE-autentikaasje. De bewiismiddels kinne gelyk wêze oan it gefal mei mear omgongen, wylst it protokoll ien omgong yn stee fan twa draacht. Dêrom mislearret in ûntwerp dat út in EAP-TLS-ynstallaasje kopiearre is krekt op it punt dêr't it twadde bewiis ferwachte wurdt.

Hetzelfde bestân lêst oars op 'e gateway

Hetzelfde swanctl-bestân wurdt oars lêzen ôfhinklik fan wêr't it rint, en dat is it part dêr't minsken oer stroffelet. Op 'e laptop is de gateway de tsjinpartij, en op 'e gateway is de laptop dat, dus skriuw de local-kant as wa't ik bin en de remote-kant as wa't ik akseptearje sil. In local-blok beskriuwt hoe't dit einpunt himsels autentisearret, en in remote-blok jout oan wat it fan 'e oare kant easket. In blok tusken de twa bestannen kopiearje keart de betsjutting om sûnder ien teken te feroarjen. De twa bestannen ferlykje fertelt jo hast neat, want deselde wurden betsjutte yn elk it tsjinoerstelde.

De posysje fan in ôfdieling bepaalt syn oarder, útsein as in omgongsnummer him oerhearsket. Sadwaande beskriuwe ekstra local- of remote-ôfdielings ekstra omgongen en gjin alternativen, en it eksplisite omgongsnummer yn swanctl.conf-referinsje bestiet krekt om dy oardering bewust te meitsjen. Sûnder dat feroaret it ferpleatsen fan in blok it gedrach. Dêrom kinne ek twa konfiguraasjes dy't op papier gelykweardich lykje, har yn tsjinoerstelde oarder hâlde.

Dy oarderingsregel produsearret de mislearringswize dy't it wurdich is om te ûnthâlden. In twadde remote-blok is gjin oare akseptabele opsje; it is in twadde eask, en dêrom hâldt in belied dat as of/of lêzen wurdt him as en-dan. In gatewaybelied kin it sertifikaat fan 'e ynskreaune masine akseptearje en dan de EAP-útwikseling fan dy brûker easkje, yn dy oarder.

Underskied omgongen fan ûnôfhinklike faktoaren

Twa omgongen binne net automatysk twa ûnôfhinklike faktoaren. In bewiis werhelje, of twa bewiismiddels yn itselde bewarplak hâlde, jout net de krêft dy't it ûntwerp tafoegje moatten hie. Ûnôfhinklikheid is in eigenskip fan hoe't de geheimen holden wurde en wat se kompromittearret, net fan hoefolle útwikselings it protokoll docht. In ûntwerp dat omgongen as faktoaren telt, oerskat wat it hat. Dat ûnderskied is it wichtichst as in foldwaanheidsfraach freget hoefolle faktoaren de oanmelding eins brûkt.

In masinesertifikaat bewissiget it besit fan syn akseptearre kaai, en net mear. It is gjin hardware-attestaasje en gjin apparaat-sûnensrapport, dus in belied dat postuerynformaasje nedich hat, hat in oar meganisme nedich. It subject-fjild is ek gjin ynventarislabel dêr't jo op fertrouwe kinne, want it subject wurdt keazen troch wa't it sertifikaat útjûn of ynskreaun hat. As it ûntwerp in bewiis nedich hat dat de masine sûn is, moat dat bewiis komme fan in komponint dat de masine mjit.

Skriuw op wat elke omgong eins bewissiget foardat jo him tafoegje. As twa omgongen itselde twa kear bewissigje, foeget de twadde wachttiid en stipekaartsjes ta ynstee fan fêstichheid. Dy notysje is ek wat in diskusje stopt oer de fraach oft de ekstra omgong syn kosten wurdich is.

Skriuw de pearenregel en test de ôfwizings

Beslis hokker masine-identiteiten mei hokker minsken pearje meie, en skriuw de regel dêr't de hanthavening wennet. Twa jildige bewiismiddels njonken elkoar bewissigje neat oer it pearen, want it pearen is in autorisaasjebeslissing en net in autentikaasje-útkomst. De ynskriuwingsregistraasjes of de autentikaasje-backend moatte de relaasje hanthavenje dy't de organisaasje wol.

Test dan wat mislearje moat: in akseptearre brûker op in net-goedkarde masine, in net-goedkarde brûker mei de bewiismiddels fan 'e masine, en in tsjinpartij dy't de ekstra omgong net dwaan kin. As alle trije stil itselde tagong krije, beskriuwt it belied in bedoeling ynstee fan him te hanthavenjen. Ferlykje de ferklearre konfiguraasje mei wat de daemon rapportearret, want in ferbining dy't nea past hat liket identyk op in regel dy't slagge is:

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

Kontrolearje de ûnderhannele omgongen en de autorisaasje dy't dêrút folget, net allinnich de suksesfolle oanmelding. En gryp net nei âlde IKEv1 XAuth-ynstellingen as koarte paad: lykje it protokoll, de rollen, de oarder en it echte gedrach fan 'e kliïnt ôf ynstee fan in ferplichte omgong te skrassen oant in ferbining slagget. It skrassen fan 'e omgong dy't mislearret is hoe't in ûntwerp mei twa bewizen stil in ûntwerp mei ien bewiis wurdt dat nimmen neisjoen hat. Hâld it skrassen yn it feroaringsregister.