Kako se hibridna avtentikacija IKEv1 preslika v avtentikacijo uporabnikov v IKEv2
Hibridni način je ločeval dokaz prehoda od dokaza uporabnika. Prehod na IKEv2 ohranja to ločitev, a spreminja izmenjavo, metodo EAP in preverjanja certifikata.
Vsak star profil VPN, ki najprej zahteva strežniški certifikat in nato uporabniško ime, nosi dva dogodka avtentikacije v eni izmenjavi, in ta oblika preživi protokol, ki jo je uvedel. Hibridni način IKEv1 je bil zgrajen prav za to: prehod se dokaže z javnim ključem, uporabnik pa se dokaže pozneje prek XAuth. IKEv2 izraža isto dvostopenjsko zamisel z drugačnim mehanizmom, in prav v teh razlikah migracije spodletijo. Nobena številka različice ne pretvori enega v drugo, in kopiranje starih imen možnosti v nov profil da odjemalca, ki se pogaja in nato ničesar ne avtenticira.
Kaj je hibridni način počel znotraj IKEv1
V hibridnem profilu odzivnik podpiše izmenjavo prve faze s svojim certifikatom, medtem ko iniciator namerno ne predloži nobenega. Dokaz identitete je torej asimetričen, in to je prehodu omogočilo, da obdrži obstoječi PKI, uporabniki pa svoja imenikova gesla. Ko se prva faza konča, XAuth teče kot zahteva in odgovor, ki nosita atribute uporabniškega imena in gesla v zdaj šifriranem kanalu ISAKMP.
Bodite pozorni, kam pade zaupanje. Certifikat odgovori, do katerega prehoda je odjemalec prišel; XAuth odgovori, kateri uporabnik želi dostop. Nobeno ne nadomesti drugega, in odjemalec, nastavljen na sprejemanje katerega koli strežniškega certifikata, je prvi odgovor tiho zavrgel. Oznaka hibridni se uporablja tudi za agresivni način s predhodno izmenjanim ključem in XAuth, drugačna ureditev z enako uporabniško izkušnjo, zato berite profil in ne imena. Obe različici izhajata iz osnutkov, ki nikoli niso postali standardi, in zato lahko dva proizvajalca uvedeta hibridni način in ne sodelujeta z nobenim.
Kako IKEv2 doseže isti dve dokazili
IKEv2 razdeli delo med IKE_SA_INIT in IKE_AUTH. Prva izmenjava dogovori predloge in ključe povsem brez identitet; druga nosi IDi, IDr in tovore AUTH. Pod EAP prvi tovor AUTH iniciatorja odide prazen, odzivnik se najprej avtenticira s certifikatom in podpisom, nato pa pogovor EAP teče znotraj sporočil IKE_AUTH.
Mehanizem, ki to naredi varno, je ključni material. Uspešna metoda EAP izvozi sejni ključ, in končni tovor AUTH iniciatorja se izračuna iz njega, tako da sta dokaz uporabnika in ključi tunela povezana. XAuth nima ustreznika: njegovi atributi pridejo po prvi fazi in h ključem ne prispevajo ničesar. Prav to vrzel je bil okvir IKEv2 zasnovan zapreti, in zato delujoča prijava IKEv2 preveri strežniški certifikat, preden karkoli zahteva.
Ta vrstni red je tudi koristna diagnostika. Ko se odjemalec pritožuje zaradi poverilnic, preden vam je pokazal certifikat, sploh ne izvaja izmenjave EAP v IKEv2.
Tri identitete naj ostanejo ločene
Migracija gre narobe, ko se tri identitete zlijejo v eno polje. Tu je identiteta prehoda, ki jo odjemalec preveri, običajno ime DNS v subject ali SAN certifikata. Tu je identiteta uporabnika, predstavljena v EAP, morda domenska prijava, naslov ali izrecni niz identitete EAP. In tu je vir avtorizacije, ki tega uporabnika preslika v omrežja in poti.
Sintaksa swanctl v strongSwan naredi ločitev vidno: povezava nastavi remote { auth = pubkey } za prehod in local { auth = eap-mschapv2 } za uporabnika, identiteta EAP pa se prenaša ločeno.
Ko se identiteta uporabnika v novem profilu razlikuje od starih atributov XAuth, na primer UPN namesto kratkega imena, strežnik za avtentikacijo vidi neznanega uporabnika in napaka je videti kot napačno geslo. Preverite niz identitete, preden preverite poverilnice.
Preslikajte možnosti in nato pričakujte pasti
Preslikava je kratka in vsaka vrstica ima past, ki se pokaže šele ob avtentikaciji.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Nobena od teh vrstic ni zgolj preimenovanje. Konfiguracijski tovor dostavi naslove in razreševalnike prek tipiziranega seznama atributov, medtem ko je bil atributni prostor XAuth lasten izum; obravnavati jih kot zamenljive je pot, po kateri profil zahteva nastavitev, ki je prehod nikoli ne bo poslal.
Selektorji prometa si zaslužijo svoje opozorilo. IKEv1 je zanimiv promet izražal s proxy ID, vezanimi na izmenjavo quick mode, medtem ko IKEv2 selektorje pogaja med IKE_AUTH in odzivnik jih lahko zoži. Neskladje ustvari vzpostavljen IKE SA brez child SA, ki ga nekateri odjemalci veselo prikažejo kot povezanega.
Staro povezavo obravnavajte kot mejo
RFC 9395 razglasi IKEv1 za zastarelega, zato je stara hibridna povezava meja združljivosti z datumom, ne temelj. Zaženite oba profila vzporedno med spremembo, ker preskus, ki šteje, ni ali se nov profil dvigne, ampak ali isti uporabnik na isti napravi doseže iste vire.
Preverjanje certifikatov naj bo strogo ves čas. Ko odjemalec preneha predložiti svoj certifikat, je skušnjava popustiti pri preverjanju strežnika, dokler se rokovanje ne konča, in to zamenja edini preostali dokaz za zeleno ikono.
Preden star profil upokojite, zapišite štiri stvari: metodo EAP, niz identitete, vir avtorizacije in datum, ko se podpora konča.