Ako sa hybridná autentizácia IKEv1 premieta do autentizácie používateľov v IKEv2
Hybridný režim oddeľoval dôkaz brány od dôkazu používateľa. Prechod na IKEv2 toto oddelenie zachováva, ale mení výmenu, metódu EAP a kontroly certifikátu.
Každý starý profil VPN, ktorý najprv žiada certifikát servera a potom používateľské meno, nesie v jednej výmene dve autentizačné udalosti a tento tvar prežíva protokol, ktorý ho zaviedol. Hybridný režim IKEv1 vznikol presne pre toto: brána sa preukazuje verejným kľúčom a používateľ sa preukazuje neskôr cez XAuth. IKEv2 vyjadruje rovnakú dvojkrokovú myšlienku inou mechanikou a práve v tých rozdieloch migrácie zlyhávajú. Žiadne číslo verzie neprevedie jedno na druhé a kopírovanie starých názvov volieb do nového profilu dá klienta, ktorý vyjedná a potom nič neautentizuje.
Čo hybridný režim robil vnútri IKEv1
V hybridnom profile respondent podpisuje výmenu prvej fázy svojím certifikátom, zatiaľ čo iniciátor zámerne žiadny nepredkladá. Dôkaz totožnosti je teda asymetrický, a to umožnilo bráne zachovať existujúcu PKI, kým používatelia si nechali svoje adresárové heslá. Keď sa prvá fáza dokončí, XAuth beží ako požiadavka a odpoveď, ktoré nesú atribúty používateľského mena a hesla v už šifrovanom kanáli ISAKMP.
Všimnite si, kde končí dôvera. Certifikát odpovedá na to, ku ktorej bráne sa klient dostal; XAuth odpovedá na to, ktorý používateľ chce prístup. Ani jedno nenahrádza druhé a klient nastavený tak, aby prijal akýkoľvek certifikát servera, prvú odpoveď ticho zahodil. Označenie hybridný sa používa aj pre agresívny režim s vopred zdieľaným kľúčom plus XAuth, iné usporiadanie s rovnakou používateľskou skúsenosťou, takže čítajte profil, nie názov. Oba varianty pochádzajú z návrhov, ktoré sa nikdy nestali štandardmi, a preto dvaja výrobcovia môžu hybridný režim implementovať a nespolupracovať s nikým.
Ako IKEv2 dosahuje rovnaké dva dôkazy
IKEv2 delí prácu medzi IKE_SA_INIT a IKE_AUTH. Prvá výmena dohodne návrhy a kľúče úplne bez identít; druhá nesie IDi, IDr a užitočné zaťaženia AUTH. Pod EAP odchádza prvé zaťaženie AUTH iniciátora prázdne, respondent sa najprv autentizuje certifikátom a podpisom a potom rozhovor EAP beží vnútri správ IKE_AUTH.
Mechanizmom, ktorý to robí bezpečným, je kľúčový materiál. Úspešná metóda EAP exportuje kľúč relácie a konečné zaťaženie AUTH iniciátora sa z neho počíta, takže dôkaz používateľa a kľúče tunela sú zviazané. XAuth nemá náprotivok: jeho atribúty prichádzajú po prvej fáze a ku kľúčom ničím neprispievajú. Presne túto medzeru mal rámec IKEv2 uzavrieť, a preto fungujúce prihlásenie IKEv2 overí certifikát servera skôr, než sa na čokoľvek opýta.
Toto poradie je aj užitočná diagnostika. Keď sa klient sťažuje na prihlasovacie údaje skôr, než vám ukázal certifikát, nevykonáva vôbec výmenu EAP v IKEv2.
Udržujte tri identity oddelené
Migrácia sa pokazí, keď sa tri identity zlejú do jedného poľa. Je tu identita brány, ktorú klient overuje, zvyčajne meno DNS v subject alebo SAN certifikátu. Je tu identita používateľa predkladaná v EAP, možno doménové prihlásenie, adresa alebo výslovný reťazec identity EAP. A je tu zdroj autorizácie, ktorý tohto používateľa mapuje na siete a trasy.
Syntax swanctl v strongSwan robí rozdelenie viditeľným: spojenie nastavuje remote { auth = pubkey } pre bránu a local { auth = eap-mschapv2 } pre používateľa, pričom identita EAP sa prenáša zvlášť.
Keď sa identita používateľa v novom profile líši od starých atribútov XAuth, napríklad UPN namiesto krátkeho mena, autentizačný server vidí neznámeho používateľa a zlyhanie vyzerá ako nesprávne heslo. Skontrolujte reťazec identity skôr, než skontrolujete prihlasovacie údaje.
Zmapujte voľby a potom čakajte pasce
Mapovanie je krátke a každý riadok má pascu, ktorá sa objaví až pri autentizácii.
| 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 |
Žiadny z tých riadkov nie je obyčajným premenovaním. Konfiguračné zaťaženie doručuje adresy a prekladače cez typovaný zoznam atribútov, kým priestor atribútov XAuth bol vlastným vynálezom; považovať ich za zameniteľné je cesta, ako profil skončí žiadosťou o nastavenie, ktoré brána nikdy nepošle.
Selektory prevádzky si zaslúžia vlastné varovanie. IKEv1 vyjadroval zaujímavú prevádzku pomocou proxy ID viazaných na výmenu quick mode, kým IKEv2 vyjednáva selektory počas IKE_AUTH a respondent ich môže zúžiť. Nezhoda vytvorí ustavené IKE SA bez child SA, ktoré niektorí klienti veselo zobrazujú ako pripojené.
Berte staré spojenie ako hranicu
RFC 9395 označuje IKEv1 za zastarané, takže staré hybridné spojenie je hranica kompatibility s dátumom, nie základ. Prevádzkujte oba profily počas zmeny súbežne, pretože rozhodujúci test nie je, či nový profil naskočí, ale či ten istý používateľ na tom istom zariadení dosiahne tie isté zdroje.
Udržujte overovanie certifikátov prísne po celý čas. Keď klient prestane predkladať vlastný certifikát, pokušenie je zmierniť kontrolu servera, kým sa handshake nedokončí, a to vymení jediný zostávajúci dôkaz za zelenú ikonu.
Než starý profil vyradíte, zapíšte si štyri veci: metódu EAP, reťazec identity, zdroj autorizácie a dátum, kedy podpora skončí.