Jak se hybridní autentizace IKEv1 promítá do autentizace uživatelů v IKEv2
Hybridní režim odděloval důkaz brány od důkazu uživatele. Přechod na IKEv2 toto oddělení zachovává, ale mění výměnu, metodu EAP a kontroly certifikátu.
Každý starý profil VPN, který nejprve žádá certifikát serveru a potom uživatelské jméno, nese v jedné výměně dvě autentizační události a tento tvar přežívá protokol, který jej zavedl. Hybridní režim IKEv1 vznikl přesně pro toto: brána se prokazuje veřejným klíčem a uživatel se prokazuje později přes XAuth. IKEv2 vyjadřuje stejnou dvoukrokovou myšlenku jinou mechanikou a právě v těch rozdílech migrace selhávají. Žádné číslo verze nepřevádí jedno na druhé a kopírování starých názvů voleb do nového profilu dá klienta, který vyjedná a pak nic neautentizuje.
Co hybridní režim dělal uvnitř IKEv1
V hybridním profilu respondent podepisuje výměnu první fáze svým certifikátem, zatímco iniciátor záměrně žádný nepředkládá. Důkaz totožnosti je tedy asymetrický, a to umožnilo bráně zachovat stávající PKI, zatímco uživatelé si nechali svá adresářová hesla. Když první fáze skončí, XAuth běží jako požadavek a odpověď, které nesou atributy uživatelského jména a hesla v už šifrovaném kanálu ISAKMP.
Všimněte si, kde končí důvěra. Certifikát odpovídá na to, ke které bráně se klient dostal; XAuth odpovídá na to, který uživatel chce přístup. Ani jedno nenahrazuje druhé a klient nastavený tak, aby přijal jakýkoli certifikát serveru, první odpověď tiše zahodil. Označení hybridní se používá i pro agresivní režim s předem sdíleným klíčem plus XAuth, jiné uspořádání se stejnou uživatelskou zkušeností, takže čtěte profil, ne název. Obě varianty pocházejí z návrhů, které se nikdy nestaly standardy, a proto dva výrobci mohou hybridní režim implementovat a nespolupracovat s nikým.
Jak IKEv2 dosahuje stejných dvou důkazů
IKEv2 dělí práci mezi IKE_SA_INIT a IKE_AUTH. První výměna dohodne návrhy a klíče zcela bez identit; druhá nese IDi, IDr a užitečná zatížení AUTH. Pod EAP odchází první zatížení AUTH iniciátora prázdné, respondent se nejprve autentizuje certifikátem a podpisem a poté rozhovor EAP běží uvnitř zpráv IKE_AUTH.
Mechanismem, který to činí bezpečným, je klíčový materiál. Úspěšná metoda EAP exportuje klíč relace a konečné zatížení AUTH iniciátora se z něj počítá, takže důkaz uživatele a klíče tunelu jsou svázány. XAuth nemá protějšek: jeho atributy přicházejí po první fázi a ke klíčům ničím nepřispívají. Přesně tuto mezeru měl rámec IKEv2 uzavřít, a proto fungující přihlášení IKEv2 ověřuje certifikát serveru dřív, než se na cokoli zeptá.
Toto pořadí je také užitečná diagnostika. Když si klient stěžuje na přihlašovací údaje dřív, než vám ukázal certifikát, neprovádí vůbec výměnu EAP v IKEv2.
Udržujte tři identity oddělené
Migrace se pokazí, když se tři identity slijí do jednoho pole. Je tu identita brány, kterou klient ověřuje, obvykle jméno DNS v subject nebo SAN certifikátu. Je tu identita uživatele předkládaná v EAP, možná doménové přihlášení, adresa nebo výslovný řetězec identity EAP. A je tu zdroj autorizace, který tohoto uživatele mapuje na sítě a trasy.
Syntaxe swanctl v strongSwan činí rozdělení viditelným: spojení nastavuje remote { auth = pubkey } pro bránu a local { auth = eap-mschapv2 } pro uživatele, přičemž identita EAP se přenáší zvlášť.
Když se identita uživatele v novém profilu liší od starých atributů XAuth, například UPN místo krátkého jména, autentizační server vidí neznámého uživatele a selhání vypadá jako špatné heslo. Zkontrolujte řetězec identity dřív, než zkontrolujete přihlašovací údaje.
Zmapujte volby a pak čekejte pasti
Mapování je krátké a každý řádek má past, která se objeví až při autentizaci.
| 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 |
Žádný z těch řádků není pouhým přejmenováním. Konfigurační zatížení doručuje adresy a překladače přes typovaný seznam atributů, zatímco prostor atributů XAuth byl vlastním vynálezem; považovat je za zaměnitelné je cesta, jak profil skončí žádostí o nastavení, které brána nikdy nepošle.
Selektory provozu si zaslouží vlastní varování. IKEv1 vyjadřoval zajímavý provoz pomocí proxy ID vázaných na výměnu quick mode, zatímco IKEv2 vyjednává selektory během IKE_AUTH a respondent je může zúžit. Neshoda vytvoří ustavené IKE SA bez child SA, které někteří klienti vesele zobrazují jako připojené.
Berte staré spojení jako hranici
RFC 9395 označuje IKEv1 za zastaralé, takže staré hybridní spojení je hranice kompatibility s datem, ne základ. Provozujte oba profily během změny souběžně, protože rozhodující test není, zda nový profil naskočí, ale zda stejný uživatel na stejném zařízení dosáhne stejných prostředků.
Udržujte ověřování certifikátů přísné po celou dobu. Jakmile klient přestane předkládat vlastní certifikát, pokušení je zmírnit kontrolu serveru, dokud se handshake nedokončí, a to vymění jediný zbývající důkaz za zelenou ikonu.
Než starý profil vyřadíte, zapište si čtyři věci: metodu EAP, řetězec identity, zdroj autorizace a datum, kdy podpora skončí.